nRF52840 power-on reset failure

[JordanYates]

Under the recommended operating conditions (page 611) in the nRF52840 datasheet, there is a note specifying:

Important: The on-chip power-on reset circuitry may not function properly for rise times longer
than the specified maximum.

Given a device (with SWD access), is there any way to detect whether the POR circuitry has failed?

Is the error condition when this occurs the same as was stated for the nRF52832 here? (stay in reset state with no code running) 
https://devzone.nordicsemi.com/f/nordic-q-a/47531/power-on-reset-on-nrf52832

We have several devices that we suspect to be in this mode, but wish to validate.
The behavior we can observe is:

• The standard software is not running (it contains a watchdog)
• SoC is being supplied 3.3V
• Pin 18 is configured as nRESET (implying an internal pull-up resistor), but the nRESET pin is low
• Physically pulling nRESET high does not result in code executing
• We are unable to connect to the device using JLinkExe tools
• Physically disconnecting the battery and reinserting it resolves the issue (code starts executing)

[Simonr]

Hi

Please check out this case, where my colleague Jimmy has provided some information as to how you can store the error code in your Flash memory and print out the reset reason (NRF_POWER->RESETREAS) after the system powers up.

Best regards,

Simon

[JordanYates]

Hi Simon.

I believe the RESETREAS register will be of limited use as the only way we have currently found to recover these devices is to remove power from them. The problem is that the system doesn't power up, despite the voltage being sufficient. On devices that do recover from being flat (i.e not the problem I am trying to resolve), the RESETREAS register is typically 0x00, as would be expected.

Cheers,
Jordan

[Simonr]

Hi

Okay, are the rise times for your battery longer than have you measured the VDD to make sure the voltage supply is consistent. What does your application do exactly? When debugging, what do you see in terms of logging information? What does the rise time look like on your end, if they are above 60ms, undefined behavior like this may indeed occur, and if so I would suggest looking into what's causing such a high supply rise time.

Best regards,

Simon

[JordanYates]

Hi Simon,

The devices are solar powered, and semi-regularly recovering from a flat battery. The voltage and current the battery can support at this point varies with light intensity, and we cannot currently make guarantee's about rise times.

We are simply hoping to confirm that the problem we are seeing is the POR failing, so we can make rectifications in the future.

As noted above, there is no logging output because the CPU does not appear to be running. SEGGER JLink tools are unable to connect to the device, despite the voltage reading as 3.3V.

Ignoring the more complicated functionality, the application should broadcast on Bluetooth and flash an LED when a button is pushed.

[Simonr]

Okay, I think this would be the POR failing, but I can't confirm it just from your description, but I think it's safe to say that what's causing this is the long rise times. Our expert on the matter is out of office today, but I'll ask him first thing on Monday whether he can provide some more details on whether there's some way to pin point whether it's the POR or something else failing.

For future HW revisions of your device I would suggest adding some kind of threshold between the solar panels and VDD on the nRF52 so that the nRF won't be provided power until there is enough to make the device run to prevent these extended rise times.

Best regards,

Simon