-
Notifications
You must be signed in to change notification settings - Fork 60
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
[nrf toup] getting boot reason on nRF54h20 #513
base: master
Are you sure you want to change the base?
[nrf toup] getting boot reason on nRF54h20 #513
Conversation
kg-nordicsemi
commented
Nov 25, 2024
- Use NRF_RESETINFO register to get boot reason
@@ -28,19 +28,7 @@ | |||
namespace chip { | |||
namespace DeviceLayer { | |||
|
|||
#if defined(CONFIG_ARCH_POSIX) || defined(CONFIG_SOC_SERIES_NRF54HX) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this change needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because in nrf54h20 case we don't use Reboot function right? we use dfu_target_suit_reboot. Reset reason is saved in RESETINFO register, so we also don't need to use GetSoftwareRebootReason(), so I thought it is unnecessary to define these functions in case of using nrf54h20.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In case of nRF54H20 that's true, but what about POSIX? Will this change work in Matter upstream repo? You've assigned it as [nrf toup].
return BootReasonType::kBrownOutReset; | ||
} | ||
|
||
if (reason & RESETINFO_RESETREAS_GLOBAL_DOG_Msk) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about changing ifs to else ifs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is subjective, but this is actually opposite to what clang-tidy
considers readability improvement: https://clang.llvm.org/extra/clang-tidy/checks/readability/else-after-return.html :)
@@ -60,6 +64,32 @@ namespace { | |||
BootReasonType DetermineBootReason() | |||
{ | |||
#ifdef CONFIG_HWINFO | |||
|
|||
#ifdef CONFIG_SOC_SERIES_NRF54HX | |||
uint32_t reason = nrf_resetinfo_resetreas_global_get(NRF_RESETINFO); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any chance to stop using nrf_
specific API, and instead use HW_INFO module or similar? Probably new nrfx which will be part of NCS 2.9.0 introduces support for nRF54H20 and reset reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried using hwinfo_get_reset_cause, but it doesn't work with nrf54h20 for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we know when or how it is planned to be supported?
@@ -60,6 +64,32 @@ namespace { | |||
BootReasonType DetermineBootReason() | |||
{ | |||
#ifdef CONFIG_HWINFO | |||
|
|||
#ifdef CONFIG_SOC_SERIES_NRF54HX |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this code doesn't depend on HWINFO, so why is it inside #ifdef CONFIG_HWINFO
?
(RESETINFO_RESETREAS_GLOBAL_RESETPOR_Msk | RESETINFO_RESETREAS_GLOBAL_SECSREQ_Msk)) | ||
{ | ||
return BootReasonType::kSoftwareUpdateCompleted; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't you need to clear the reset cause somewhere so that it is not accumulated in subsequent reboots?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't see any api to do this, but I tested manually several reboot reasons, and it seems that everything works as expected
69d980e
to
5ac2b95
Compare
if ((reason & (RESETINFO_RESETREAS_GLOBAL_RESETPOR_Msk | RESETINFO_RESETREAS_GLOBAL_SECSREQ_Msk)) == | ||
(RESETINFO_RESETREAS_GLOBAL_RESETPOR_Msk | RESETINFO_RESETREAS_GLOBAL_SECSREQ_Msk)) | ||
{ | ||
return BootReasonType::kSoftwareUpdateCompleted; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, how do we know it was caused by the SoftwareUpdate, and not for example crash, or reset from the application layer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I performed several manual tests, and checked what are the values returned from RESETINFO in different cases, for example:
- reset after DFU over Matter -> returned value: 528
- reset using button on board -> returned value:514
- reset from the application -> returned value: 0
- reset from disabling power supply -> returned value: 1
Events has unique values, and thanks to it, it can be parsed to actual boot reason
But, I don't know what is returning when board is crashing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but I RESETINFO_RESETREAS_GLOBAL_RESETPOR_Msk | RESETINFO_RESETREAS_GLOBAL_SECSREQ_Msk
does not seem to mean that Firmware Upgrade has been done - and the event to Matter core might be generate incorrectly.
We need to either find out if suit
module might indicate it, or find some register/retention RAM to store information about reset being scheduled due to image update, not for other reason.
@SylwesterKonczyk @tomchy maybe might help if we have anything like this in SUIT, else we need to look at different way.
e5809a0
to
286f3d3
Compare
#endif | ||
|
||
#ifdef CONFIG_SOC_SERIES_NRF54HX | ||
reason = nrf_resetinfo_resetreas_global_get(NRF_RESETINFO); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to not use this API as it is HW specific.
What about to wait for this PR: nrfconnect/sdk-zephyr#2293 as dependency. And use the API of HW_INFO instead?
286f3d3
to
e39f5ca
Compare
src/platform/SaveBootReasonDFUSuit.h
Outdated
#ifndef NRF_SAVE_BOOT_REASON_H__ | ||
#define NRF_SAVE_BOOT_REASON_H__ | ||
|
||
extern int BootReason; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you do it in this way?
@@ -182,6 +185,8 @@ CHIP_ERROR OTAImageProcessorImpl::Apply() | |||
PlatformMgr().HandleServerShuttingDown(); | |||
k_msleep(CHIP_DEVICE_CONFIG_SERVER_SHUTDOWN_ACTIONS_SLEEP_MS); | |||
#ifdef CONFIG_DFU_TARGET_SUIT | |||
BootReason = 5; | |||
ChipLogDetail(DeviceLayer, "Software Boot reason %d", BootReason); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Debug log?
@@ -182,6 +185,8 @@ CHIP_ERROR OTAImageProcessorImpl::Apply() | |||
PlatformMgr().HandleServerShuttingDown(); | |||
k_msleep(CHIP_DEVICE_CONFIG_SERVER_SHUTDOWN_ACTIONS_SLEEP_MS); | |||
#ifdef CONFIG_DFU_TARGET_SUIT | |||
BootReason = 5; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use a pre-defined value for this?
if ((reason & (RESETINFO_RESETREAS_GLOBAL_RESETPOR_Msk | RESETINFO_RESETREAS_GLOBAL_SECSREQ_Msk)) == | ||
(RESETINFO_RESETREAS_GLOBAL_RESETPOR_Msk | RESETINFO_RESETREAS_GLOBAL_SECSREQ_Msk)) | ||
{ | ||
if (BootReason == 5) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use a pre-defined value here.
uint32_t reason; | ||
#endif | ||
ChipLogDetail(DeviceLayer, "Software Boot reason %d", BootReason); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Debug log?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry I forgot to remove Debug logs
-Use NRF_RESETINFO register to get boot reason Signed-off-by: Konrad Grucel <[email protected]>
e39f5ca
to
cae80de
Compare
#ifndef NRF_SAVE_BOOT_REASON_H__ | ||
#define NRF_SAVE_BOOT_REASON_H__ | ||
|
||
inline int SoftwareBootReasonSUIT __attribute__((section(".noinit"))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please move it inside the Reboot.cpp file.
Btw. We can't have a Nordic sepecific file in the src/platform
file anyway.
Btw2. Do we need to add a SUIT
in the name?
@@ -182,6 +186,7 @@ CHIP_ERROR OTAImageProcessorImpl::Apply() | |||
PlatformMgr().HandleServerShuttingDown(); | |||
k_msleep(CHIP_DEVICE_CONFIG_SERVER_SHUTDOWN_ACTIONS_SLEEP_MS); | |||
#ifdef CONFIG_DFU_TARGET_SUIT | |||
SetSoftwareRebootReason(SoftwareRebootReason::kSoftwareUpdate); | |||
dfu_target_suit_reboot(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wonder.. Maybe we can call Reboot(SoftwareRebootReason::kSoftwareUpdate);
and inside Reboot.cpp call dfu_target_suit_reboot();
for kSoftwareUpdate
?
@ArekBalysNordic what do you think?