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

[nrf toup] getting boot reason on nRF54h20 #513

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

kg-nordicsemi
Copy link
Contributor

  • 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)
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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)
Copy link
Contributor

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?

Copy link
Contributor

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);
Copy link
Collaborator

@LuDuda LuDuda Nov 26, 2024

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.

Copy link
Contributor Author

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

Copy link
Contributor

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
Copy link
Contributor

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;
}
Copy link
Contributor

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?

Copy link
Contributor Author

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

@kg-nordicsemi kg-nordicsemi force-pushed the save-reboot-reason-nrf54h20 branch from 69d980e to 5ac2b95 Compare November 27, 2024 14:05
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;
Copy link
Collaborator

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?

Copy link
Contributor Author

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

Copy link
Collaborator

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.

@kg-nordicsemi kg-nordicsemi force-pushed the save-reboot-reason-nrf54h20 branch 2 times, most recently from e5809a0 to 286f3d3 Compare November 28, 2024 14:48
#endif

#ifdef CONFIG_SOC_SERIES_NRF54HX
reason = nrf_resetinfo_resetreas_global_get(NRF_RESETINFO);
Copy link
Collaborator

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?

@kg-nordicsemi kg-nordicsemi force-pushed the save-reboot-reason-nrf54h20 branch from 286f3d3 to e39f5ca Compare December 10, 2024 08:31
#ifndef NRF_SAVE_BOOT_REASON_H__
#define NRF_SAVE_BOOT_REASON_H__

extern int BootReason;
Copy link
Contributor

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);
Copy link
Contributor

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;
Copy link
Contributor

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)
Copy link
Contributor

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);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Debug log?

Copy link
Contributor Author

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]>
@kg-nordicsemi kg-nordicsemi force-pushed the save-reboot-reason-nrf54h20 branch from e39f5ca to cae80de Compare December 10, 2024 16:00
#ifndef NRF_SAVE_BOOT_REASON_H__
#define NRF_SAVE_BOOT_REASON_H__

inline int SoftwareBootReasonSUIT __attribute__((section(".noinit")));
Copy link
Collaborator

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();
Copy link
Collaborator

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?

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

Successfully merging this pull request may close these issues.

4 participants