nRF Desktop Failsafe module: migration to the Zephyr HWinfo driver and activation on the nRF54H20 DK #19142
Conversation
Updated sdk-zephyr to include the Zephyr HWinfo driver. Signed-off-by: Kamil Piszczek <[email protected]>
Updated the nRF Desktop Failsafe module to use the Zephyr HWinfo driver as its dependency instead of relying on the nrfx reset reason helper. Ref: NCSDK-25090 Signed-off-by: Kamil Piszczek <[email protected]>
Enabled the nRF Desktop Failsafe module in the release configuration of the nRF54H20 DK target. Ref: NCSDK-25090 Signed-off-by: Kamil Piszczek <[email protected]>
github-actions
bot
added
manifest
changelog-entry-required
|
The following west manifest projects have been modified in this Pull Request:
Note: This message is automatically posted and updated by the Manifest GitHub Action. |
CI InformationTo view the history of this post, clich the 'edited' button above Inputs:Sources:more detailsGithub labels
List of changed files detected by CI (0)Outputs:ToolchainVersion: Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
| @@ -55,17 +67,27 @@ static bool app_event_handler(const struct app_event_header *aeh) | |||
| cast_module_state_event(aeh); | |||
|
|
|||
| if (check_state(event, MODULE_ID(main), MODULE_STATE_READY)) { | |||
| int err; | |||
| bool check_result; | |||
There was a problem hiding this comment.
check_result -> erase_settings?
| @@ -15,14 +15,24 @@ | |||
| LOG_MODULE_REGISTER(MODULE, CONFIG_DESKTOP_FAILSAFE_LOG_LEVEL); | |||
|
|
|||
|
|
|||
| static bool failsafe_check(void) | |||
| static bool failsafe_check(bool *ret) | |||
There was a problem hiding this comment.
ret -> settings_erase_needed/failure_detected?
|
|
||
| *ret = ((reas & mask) != 0); | ||
|
|
||
| LOG_INF("Reset reason (0x%08X) trigger %s for Failsafe erase operation", |
There was a problem hiding this comment.
Can we make it a bit shorter: "Reset reason (0x%08X), trigger %s? Log would be prefixed with module name by the logger anyway
| { | ||
| nrfx_reset_reason_clear(nrfx_reset_reason_get()); | ||
| int err = hwinfo_clear_reset_cause(); |
There was a problem hiding this comment.
return hwinfo_clear_reset_cause(); - for simplicity?
|
|
||
| module_set_state(MODULE_STATE_READY); | ||
| if (!err) { | ||
| err = failsafe_clear(); |
There was a problem hiding this comment.
Consider avoiding clearing the reset reason if failsafe_erase call fails.
There was a problem hiding this comment.
This worked a bit differently in the previous implementation, where we cleared the reset reason unconditionally. Are you sure about that?
There was a problem hiding this comment.
I am aware that it used to work differently.
I am wondering a bit which approach would be better here: if we desist from clearing the reset reason on settings erase error, we give failsafe module another chance to erase settings which could be safer.
Depends on:
#19028
Issues:
RESET_PIN:0x00000011) or software reset (RESET_SOFTWARE:0x00000012).Out standing items: