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

Watchdog + Hard Reset

Roiger

Hi,
We are currently attempting to turn off unused parts of our RAM, and the app's linker space is configured to NOT use the turned on RAM.
The problem is that the bootloader in our production boards currently has a linker space that covers the ENTIRE board.
On the one hand we do not want the bootloader to collapse sporadically at runtime, and on the other hand we do not want to DFU the BL on our production boards, as long as this it possible...

In addition - we use a watchdog in our app, initialized by the default values:


#define NRFX_WDT_DEAFULT_CONFIG 
{ 
.behaviour = (nrf_wdt_behaviour_t)NRFX_WDT_CONFIG_BEHAVIOUR, 
.reload_value = NRFX_WDT_CONFIG_RELOAD_VALUE, 
NRFX_WDT_IRQ_CONFIG 
}

Where NRFX_WDT_CONFIG_BEHAVIOUR = 1 ("Run in SLEEP, Pause in Halt"), and NRFX_WDT_CONFIG_IRQ_PRIORITY = 6.

In addition, our timeout is set by NRFX_WDT_CONFIG_RELOAD_VALUE as 3 minutes (180000), and indeed when calling  APP_ERROR_CHECK(1) after a timer timeout, I see that the device resets after 3-3.5 minutes.
I am assuming that the device hard resets, because if I call the function for a soft reset, the board does NOT successfully reset (because some of the RAM used by the BL is off), whereas after the WD timeout, the BL --> app turns on successfully.

My question is as follows:

1) Does every assert + fault in the app lead to the watchdog instigating a hard reset?

2) Does the watchdog configured and started by the application "watch" the BL code? The reason I ask is the answer to another ticket of mine (https://devzone.nordicsemi.com/f/nordic-q-a/73584/hard-vs-soft-reset-regarding-the-bootloader-ram-off), which would lead me to believe that the series of events leading to the assumed hard reset is:
APP_ERROR_CHECK(1) --> Soft reset of app --> bootloader turns on --> bootloader fails to use some of it's RAM because it is turned off --> watchdog configured and started instigates a hard reset.

3) Continuing on the previous question - if there is a watchdog on the app code, is there any reason to start a separate watchdog on the BL code?


Thanks!
Roi

Parents
  • +1

    Hello,

    Couldn't you just re-configure the RAM retention settings before entering bootloader DFU mode?

    1) This depends on how the assert and fault handler are implemented in your application. Typically, the default behaviour for release builds is to recover from faults/errors by calling NVIC_SystemReset() (soft reset).

    2) The WDT is not reset after a soft reset (Reset behavior), so it will continue to run in the BL. The SDK bootloader will automatically feed the WD if it detects that it has been enabled by the application.

    3) It's actually not possible if the WDT was started by the application first.

    Best regards,

    Vidar

  • 0 in reply to Vidar Berg

    Very informative Vidar!! Many Thanks!
    So if I understood your answer to 2 correctly - assuming that our RAM being turned off was not turned off because of some assertion/fault, instigating a soft reset to the bootloader, and the bootloader asserts because the RAM is turned off, so since nobody feeds the WD, the device will hard reset after NRFX_WDT_CONFIG_RELOAD_VALUE  milliseconds?

    Regarding your question - we can turn the RAM back on before our planned soft resets (DFU for example), but we want to know the behavior for unplanned resets.

    Thanks!
    Roi

  • +1 in reply to Roiger

    Hi Roi,

    Good to hear that you found my reply helpful Slight smile

    The POWER[].RAM registers are retained. So as you can see from the table below, you will need a reset from  either a WD timeout, resetpin, brownout, or "power on" for the RAM power settings set by the application to become reset. This is why a Soft reset (NVIC_SystemReset) will not recover the device in this particular case.

    Roiger said:
    but we want to know the behavior for unplanned resets.

    You can change the RAM power settings before calling NVIC_SystemReset() from your fault/error handlers as well. The only challenge is that you must write directly to the memory protected POWER registers as the Softdevice APIs may not be available from the error handler. Please see this post: https://devzone.nordicsemi.com/f/nordic-q-a/53248/disable-softdevice-sandboxing-in-fault-handler. The only difference is that you want to disable protection of the POWER module, not the NVMC.

    Disabling MWU sandboxing of POWER:

    NRF_MWU->PREGION[0].SUBS &= ~(MWU_PREGION_SUBS_SR0_Include << MWU_PREGION_SUBS_SR0_Pos);
    __DSB();

    Regards

    Vidar

     

Reply
  • +1 in reply to Roiger

    Hi Roi,

    Good to hear that you found my reply helpful Slight smile

    The POWER[].RAM registers are retained. So as you can see from the table below, you will need a reset from  either a WD timeout, resetpin, brownout, or "power on" for the RAM power settings set by the application to become reset. This is why a Soft reset (NVIC_SystemReset) will not recover the device in this particular case.

    Roiger said:
    but we want to know the behavior for unplanned resets.

    You can change the RAM power settings before calling NVIC_SystemReset() from your fault/error handlers as well. The only challenge is that you must write directly to the memory protected POWER registers as the Softdevice APIs may not be available from the error handler. Please see this post: https://devzone.nordicsemi.com/f/nordic-q-a/53248/disable-softdevice-sandboxing-in-fault-handler. The only difference is that you want to disable protection of the POWER module, not the NVMC.

    Disabling MWU sandboxing of POWER:

    NRF_MWU->PREGION[0].SUBS &= ~(MWU_PREGION_SUBS_SR0_Include << MWU_PREGION_SUBS_SR0_Pos);
    __DSB();

    Regards

    Vidar

     

Children
Related