You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Set the retained value to some RunApp value (with magic number and CRC - that is implemented in Zephyr Retention system itself).
Wait for WDT reset
Check the reset source (is is WDT) - continue checking
Check the retained value (verify magic and CRC) - does in request us to start the APP?
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: