• State Verified Answer
  • Replies 5 replies
  • Subscribers 73 subscribers
  • Views 1934 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 247907
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Unexpected reset reason: POWER_RESETREAS_OFF

juliantbrown

We have a product that uses the nRF52840. We have seen that very rarely, unexpected resets happen with the reason being OFF. We have yet to encounter this issue in a lab setting, so we only have logs from devices in the field to go off of.

As far as I can tell, we should never enter the off power state. Our power management consists of calls to nrf_pwr_mgmt_run, which ultimately calls sd_app_evt_wait because we are running with the soft device enabled. Also, these resets also appear to coincide with a daily GPIO interrupt that we received from our RTC. I understand that changes in GPIO state can cause the nRF52 to wake up from the OFF power state, but it is still unclear how the nRF52 enters that state to begin with.

Is there any reason that the processor could be entering "system off" without intent? Is there any other way for these reset reason to appear? 

I should also mention that we have the workaround for the multiple reset reason errata, 136 in place already.

Thanks much!

  • 0
    I understand that changes in GPIO state can cause the nRF52 to wake up from the OFF power state, but it is still unclear how the nRF52 enters that state to begin with.

     If you are sure that the GPIO pin is configured with the SENSE enable to cause the DETECT signal then that particular GPIO pin have the capability to wake the chip from the System off. I see there are two things to confirm

    1. remove the SENSE capability of that gpio pin and see if this happens. Because even if the system entered erroneously into systemoff, then having no sense capability will make the system not wakeup until pin reset.
    2. I do not know of the system going into systemoff state erroneously. That would be very dangerous bug to have in our chips and I seriously doubt that it could happen (not impossible though). It is more likely that the bit is set wrong in RESETREAS in which case, I would like to know the conditions of when this is set wrong from your lab testing. If this is the case, you can just ignore this bit as your application never goes into systemoff mode, it should survive if it ignores this bit set when read and could reset it back to 0.
  • 0 in reply to Susheel Nuguru

    Hi Susheel,

    Thanks for the response. I will double check the SENSE configuration and make sure the pin is reconfigured with SENSE disabled on one unit and run a test. 

    Understood that entering such a state unexpectedly would be very problematic. We do have the workaround for multiple reset reasons in place, as described in errata 136, but our logic does not record multiple reset reasons, so it is possible that other bits are actually asserted. I will make a change to report multiple reset reasons and report back with any findings as we narrow down the conditions surrounding this event. 

    If anything comes to mind regarding experiments you’d suggest I run, let me know. Thanks!

  • 0 in reply to juliantbrown
    juliantbrown said:
    If anything comes to mind regarding experiments you’d suggest I run, let me know. Thanks!

     Will do Julian. Please come to update me with your test results.

  • +1 in reply to Susheel Nuguru

    Hi Susheel,

    Another update here. We were able to reproduce the problem and isolate the circumstance that causes it.

    First, it looks like the actually reason for reset was a watchdog, but both the OFF and DOG reset reasons were set. This means that the nRF52 was not unexpectedly entering "system off." It does still seem unusual, however, that both reset reasons are set.

    Second, the watchdog is the result of a call to an sd_* API from the context of a GPIO interrupt, which has priority 2 on our system. I see that it is expected for such a circumstance to cause problems. This was an oversight on our part and we can fix this by scheduling the callback to the GPIO interrupt.

    Thanks for your help! It looks like the issue is resolved on our end, aside from the relatively minor unusual behavior of multiple reset reasons being set.

  • 0 in reply to juliantbrown

    Thanks for the update Julian. pushing the context away from GPIO interrupt to a scheduler is a good change.

    From Nordic side, it is a bit odd that OFF bit is set for the watchdog reset. I will ping the developers to notify about that In any case, I think you have a good fix for this not to happen.

    I would also suggest that, since your application is not doing systemoff, it can overlook at this bit and reset it whenever it sees that it is set.

Related
Terms of service