Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restart the application using watchdog (WDT) #2071

Open
rkel opened this issue Sep 23, 2024 · 1 comment
Open

Restart the application using watchdog (WDT) #2071

rkel opened this issue Sep 23, 2024 · 1 comment

Comments

@rkel
Copy link

rkel commented Sep 23, 2024

I am creating an application, for nRF chip on Zephyr environment. Using watchdog here is "must have". Also the idea is that the watchdog has to be enabled when doing DFU and when the application is started. In some of this devices the battery is non-removable and the devices are sealed - so implementing reset button would be challenging. The idea is that after an update the application has about 2 seconds to confirm itself and it always would be restarted by WDT configured by DFU to allow reverting if anything goes wrong. Application would know that it is in this "testing" state using retained part of the memory shared between bootloader and the application.

The issue I have right now is the fact that in normal operation it is the application that configures the WDT, and it does it dynamically according to its configuration. And the configuration may change after the DFU so it is hardly doable to properly configure WDT at mcuboot stage.

As far as I know nRF chips does not allow WDT reconfiguration after it was started. So the idea is to restart the CPU using WDT and decide, early before main execution, if the application should be started or the mcuboot should continue. Using such an approach means we would also not need to use nrf_cleanup_peripheral probably as the application would be started on just restarted system.

We need to use WDT reset and not software reset. At least on nRF MCUs using software reset would not clear the WDT state.

For it to work we would need to use retention system, check the reason of the reset and then check in the retained value what are we expecting to do. The idea:

  1. Set the retained value to some RunApp value (with magic number and CRC - that is implemented in Zephyr Retention system itself).
  2. Wait for WDT reset
  3. Check the reset source (is is WDT) - continue checking
  4. Check the retained value (verify magic and CRC) - does in request us to start the APP?
  5. If yes - reset the retained value and start the application, skip any device setups.

Now APP gets really clear CPU and can configure WDT to match its requirements.

For my application I would probably need also some TestApp value, where the difference would be that it starts WDT for defined time with all the channels enabled, assuming that the application does not use them all. This would allow me to do the requested restart and verify if the application confirmed itself.

Is it good approach? Any thoughts about it? I would love to get any feedbacks before I will start the implementation.

@rkel
Copy link
Author

rkel commented Sep 23, 2024

Relates to: #1673

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

1 participant