Call to sys_reboot() on nRF52840 causes hard fault

[GameCodingNinja]

Currently on SDK v2.3.0 but this problem has persisted no matter the SDK version. Here's the fault info.

[00:00:34.898,223] <err> mpsl_init: MPSL ASSERT: 112, 2195
[00:02:03.002,807] <err> os: ***** HARD FAULT *****
[00:02:03.002,807] <err> os: Fault escalation (see below)
[00:02:03.002,838] <err> os: ARCH_EXCEPT with reason 3

[00:02:03.002,838] <err> os: r0/a1: 0x00000003 r1/a2: 0x00000000 r2/a3: 0x000000bf
[00:02:03.002,838] <err> os: r3/a4: 0x00000000 r12/ip: 0x20001918 r14/lr: 0x00000000
[00:02:03.002,868] <err> os: xpsr: 0x61000018
[00:02:03.002,868] <err> os: Faulting instruction address (r15/pc): 0x0002caf8
[00:02:03.002,899] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:02:03.002,929] <err> os: Fault during interrupt handling

[00:02:03.002,960] <err> os: Current thread: 0x20002d18 (unknown)
[00:02:04.186,157] <err> fatal_error: Resetting system

I have CONFIG_REBOOT=y listed in the prj.conf file. I try to step into sys_reboot and it immediately jumps to arch_irq_lock and faults. I look through the sample projects that reboot and I don't see anything that I'm missing in the prj.conf. Not sure what to think.

Any incite would be appreciated.

[Einar Thorsrud]

Hi,

The log here shows that you get an MPSL assert which is a direct consequence of the MPSL loosing track of time due to continuing from a breakpoint or stepping. So this is a direct consequence of your debugging and not the error you are attempting to debug. Instead of stepping or continuing form a breakpoint, you can mimic the same behavior by using a breakpoint, and moving it before resetting.

Can you say more about the issue you are seeing and what you find by debugging/logging?

[GameCodingNinja]

Hi Einar,

Thanks for taking out the time to help!

Tring to reboot just appears to freeze the 52840 but what I discovered recently is that if I let it sit long enough, it appears to have rebooted. Takes about 2 minutes, 30 seconds.

Within Ozone, it will sit there and not show any signs of anything wrong. Not sure what to make of all this.

[GameCodingNinja]

Einar Thorsrud said:

The post you linked to was about the nRF5 SDK bootloader, but I remember now that you are using the nRF Connect SDK, which is completely different (using MCUBoot as a bootloader).

Yep. I'm developing under nFR Connect SDK v2.3.0. The file specified in the link and the one you highlighted is not in v2.3.0. I did some searches and came up empty handed.

[Einar Thorsrud]

Are you using a watchdog? And if so, do you still reproduce this issue if not using the watchdog? I am asking as that is a easy way to find out if what you are seeing could be something similar to in the other case (even though the SW is completely different).

[GameCodingNinja]

Einar Thorsrud said:

Are you using a watchdog?

I assume there's a hardware watchdog because the schematic shows we are using the reset pins. There's currently no code in place for "petting the dog". The 52840 will reset exactly at 2 minute and 30 seconds each time. It reboots properly once I comment out the bootloader and DFU config entries in prj.conf.

I opened up a private ticket and received some feed back from a Nordic tech engineer. I'll update you on the progress. He's having me try some tests.

[Einar Thorsrud]

Hi,

There is a WDT peripheral in the nRF, but it is not enabled by default, so if you have not enabled it it is not in use. So I think we can ignore anything related to that.

As you see this only with a bootloader and always with the same time, I wonder if perhaps you have a delay for 150 seconds waiting for DFU operation to start, and only after that the bootloader starts the application? That is quite common for serial DFU, though 150 seconds is very long and not a default value.

Anyway, there is no point in duplicating effort, so please just continue with my colleague in the other thread and update here if you make any progress.

[GameCodingNinja]

Hi Einar. The problem was identified. It was hanging in the bootloader. Adding the below to my nrf52840dk_nrf52840_defconfig solved the problem.

# 32kHz clock source

# Without the below lines, rebooting the device will hang.

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

Also added child_image folder to the project directory with a mcuboot.conf file with one config setting.

CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_MAX_SKIP=0

Vidar Berg said to make this change even though the above change fixes the problem because it's supposed to be zero. Without this change it's 1.

So we are now rebooting correctly. I'm so happy to finally get past this problem. Thank you again for your help!