This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52840 power-on reset failure

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)
Parents
  • 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

Reply
  • 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

Children
  • 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.

Related