NRF52840: VDD ramp-up to main() time.

[Hrishi]

Hi,

How much is the expected time period from the time VDD goes above 1.75V to main()? I am using a custom bootloader and am seeing a ~4.5s (yes seconds!) delay in getting to bootloader main(). When the debugger is connected this time is in the 100s of ms, which is what I would expect without the bootloader on first power up (1.8V VDD rail starting up). Here's a scope shot of my 1.8V rail (CH2) starting up and the IO (CH1) toggling (one of the first things done inside main()). Any help is greatly appreciated.

Thanks.

Hrishi

[Kenneth]

Hi,

Do you see the same problem if you are using VDD = 2.0V?

Is this measured close to the VDD pin?

What is the content of UICR after power up? Type: 'nrfjprog --readuicr dump_uicr.hex'

Any schematic to share?

Best regards,
Kenneth

[Hrishi]

Hi Kenneth,

I can not try with 2V because this is in a system powered with a 1.8V regulator. As seen in my scope shot the bus looks clean.

I checked the UICR after power-up most locations are FFs except for some of the 'reserved for Nordic firmware design' locations below:

Does this tell you anything? Where else could I be looking to debug this issue?

Thanks.

[Hrishi]

I am using a BMD-340 module.

[Kenneth]

The only explanation I have is that something is charging up, e.g. that even if you supply 1.8V, you have some series resistor/diode that limit the current going to the nRF52840 thereby keep it in some kind of reset state. That is why I wanted you try to tweak up the VDD voltage a bit to see what happens. I assume you are not able to open the module to find the exact chip markings? 

[Hrishi]

These modules are using nrF52840-QIAA production release 1 silicon. BMD-340 doesn't have anything that would slow the VCC down by 3-4 secs.

I am sure I am missing something somewhere. Could there be something in the boot-up process that may cause a long delay? Although as I mentioned earlier if I use the debugger and run the bootloader project, I do not see this huge a delay.

Thanks.

[Kenneth]

Hrishi said:

Could there be something in the boot-up process that may cause a long delay?

The below text you write that it takes ~4.5 to enter main(), so it must be electrical. I do not see how software can have anything to do with this no, since it doesn't start running any code here before you enable LED. My best suggestion is to check if VDD = 2V solve the issue (even if that will mean you have to modify the the hardware).

seeing a ~4.5s (yes seconds!) delay in getting to bootloader main()

[Hrishi]

I guess you are saying that from the time nrf52840 VDD gets above 1.75V (according to the datasheet) to the time the PC enters main.c of the bootloader I should see a time delay muc much less than 4s, correct?

Hmm this is strange. 

[Hrishi]

The BMD-340 module is getting that 1.8V VDD bus I shared in the scope shot earlier.

[Kenneth]

Hi, Is there any way you can send hardware here we may use to recreate it?

Is there any way you may try with 2V?

How have you electrically connected the BMD-340? Do you have a table that show pin connections for the module?

Were you able to try: ...open the module to find the exact chip markings? 

Hrishi said:

I guess you are saying that from the time nrf52840 VDD gets above 1.75V (according to the datasheet) to the time the PC enters main.c of the bootloader I should see a time delay muc much less than 4s, correct?

That is correct! Starting up an external 32kHz may be in the hundreds of ms, but in your case I assume you are toggling that LED in the beginning of main() so that should not apply.

[Hrishi]

Hi Kenneth,

Here's a part of the relevant schematic, which shows how the BMD-340 power pins are connected:

Here's the waveform seen at pin 39 (MCU_RSTn) along with the VDD_1V8 bus

Also for completeness my previous scope capture with the VDD_1V8 rail and the GPIO that gets toggled at the start of the bootloader main.c.

Thanks.

Hrishi

[Kenneth]

Looks good.

Is there any way you can send hardware here we may use to recreate it?

Is there any way you may try with 2V?

Can you read out content of uicr (run nrfjprog --readuicr dump.hex)?