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

Hard vs. Soft Reset, regarding the bootloader + RAM off

Roiger

Hi,
Below is the mapping of RAM on the 840 from the infocenter.
We want to utilize the functionality to turn off unused RAM (via sd_power_ram_power_clr), but we see that if we turn off sections 4 and 5 of RAM8 (2 blocks of 32 KB each), our soft reset options (DFU among them) fail to restart the device, and the only thing that can restart the device is a hard reset via the battery.
We have tried leaving the two sections on (which is a waste - since our bootloader is +- 33 KB), but we are worried that since the bootloader on our production boards has it's linker memory on the entire board, a soft reset will fail to reset the board.
To test this, I have added APP_ERROR_CHECK(1) after one of our timers times out, while turning off all the unused RAM (including sections 4 and 5 of RAM block 8, which are used by the bootloader's stack at the moment).
I expect that if APP_ERROR_CHECK should trigger a soft reset, the board will never reset (like our other soft reset options), because the RAM will not reset, and therefore the bootloader will not be able to use it's stack. On the other hand, if APP_ERROR_CHECK triggers a hard reset, the board should successfully turn on the RAM, and the bootloader --> app would run as planned.
What I saw in practice is most likely a hard reset - since the board was able to run again after a while.

My questions are as follows:

1) Is my conclusion correct in that the call to APP_ERROR_CHECK triggered a hard reset?
2) Will all assertions/faults on a release board lead to a hard reset, resetting the RAM and allowing the bootloader --> app sequence to run w/o taking the battery out of the board and putting it back?
3) The assumed hard reset after this call takes a pretty long time - around 3-3.5 minutes. Any idea why this is? Could it be because we use a watchdog?
4) Besides our calls to soft resets via sd_nvic_SystemReset, are there any other soft resets initiated by the SD that we should be aware of to turn on the turned off RAM beforehand?

Thanks!
Roi





Parents
  • +1

    Hi, 

    1) Is my conclusion correct in that the call to APP_ERROR_CHECK triggered a hard reset?

    No. The default SDK error handler will trigger a soft reset via NVIC_SystemReset().

    2) Will all assertions/faults on a release board lead to a hard reset, resetting the RAM and allowing the bootloader --> app sequence to run w/o taking the battery out of the board and putting it back?

    No. There is no reset that clears RAM explicitly (see reset behavior: "The RAM is never reset, but depending on a reset source the content of RAM may be corrupted."). The only way to confidently clear the RAM is to power-cycle the device or clear (parts of) the RAM from SW.

    3) The assumed hard reset after this call takes a pretty long time - around 3-3.5 minutes. Any idea why this is? Could it be because we use a watchdog?

    I do not see how that would be related.

    4) Besides our calls to soft resets via sd_nvic_SystemReset, are there any other soft resets initiated by the SD that we should be aware of to turn on the turned off RAM beforehand?

    The SoftDevice will not to a reset by itself, so if you have a soft reset, it is because your code (including any SDK code) does it. I cannot say which part of the SDK is relevant for you, but you can see all relevant parts by searching for NVIC_SystemReset() and sd_nvic_SystemReset() in the SDK code.

Reply
  • +1

    Hi, 

    1) Is my conclusion correct in that the call to APP_ERROR_CHECK triggered a hard reset?

    No. The default SDK error handler will trigger a soft reset via NVIC_SystemReset().

    2) Will all assertions/faults on a release board lead to a hard reset, resetting the RAM and allowing the bootloader --> app sequence to run w/o taking the battery out of the board and putting it back?

    No. There is no reset that clears RAM explicitly (see reset behavior: "The RAM is never reset, but depending on a reset source the content of RAM may be corrupted."). The only way to confidently clear the RAM is to power-cycle the device or clear (parts of) the RAM from SW.

    3) The assumed hard reset after this call takes a pretty long time - around 3-3.5 minutes. Any idea why this is? Could it be because we use a watchdog?

    I do not see how that would be related.

    4) Besides our calls to soft resets via sd_nvic_SystemReset, are there any other soft resets initiated by the SD that we should be aware of to turn on the turned off RAM beforehand?

    The SoftDevice will not to a reset by itself, so if you have a soft reset, it is because your code (including any SDK code) does it. I cannot say which part of the SDK is relevant for you, but you can see all relevant parts by searching for NVIC_SystemReset() and sd_nvic_SystemReset() in the SDK code.

Children
Related
Terms of service