[nRF54L15-DK] The SoC keeps being woken up from System OFF by the onboard debugger

[mkoclega]

Hi. I'm working on a code that performs an action and immediately goes into System OFF mode. Before that, it configures GRTC as a wake-up source with a 5 secs timeout.
I've used the official sample as a reference.

The problem I'm having is that when I power cycle the DK, the behavior is random and there are 3 scenarios that I've observed:
- the code works as expected (this one is not very common),
- the code resets immediately after going to System OFF with debugger reset cause (RESET_DEBUG) - this one is the most common,
- sometimes the code seems to not even start (it's rare).

I've tried to enable/disable multiple options in prj.conf but still cannot tell what may be causing this. The console/logging is disabled.
After the debugger reset the exact reason is the DIF bit in RESETREAS register.

I'm not debugging the code, I just use the onboard debugger for flashing.

My DK is v 1.0.0 (2025.36), I'm using SDK 3.1.1 integrated into VS Code.

I've posted my code here: mkoclega/nrf54l15dk-system-off-test

Thanks - Mariusz

[mkoclega]

Hi,

I just pushed a fix for flash_led() function. The behavior seems to be the same with that fix. I don't have CONFIG_RESET_ON_FATAL_ERROR set to 'y' (checked in the Kconfig GUI in Libraries -> Reset on fatal error). So if no LED blinks I guess the reset cause is different than the four I handled in the code, I'll check that in the evening.

Yes, I'm aware of a background thread, and waiting an arbitrary time for it to finish is not a good option. So in my initial PoC app I simply set CONFIG_LOG_MODE_IMMEDIATE=y and also tried to call log_flush() just before suspending console, but it didn't have any impact on the issue.

I'm new to Nordic SoCs and I still need to learn debugging on that platform. So not sure when I'm ready with that.

I'm not sure if I got you right, you were able to reproduce the debugger reset loop issue on your end, is that right?

[mkoclega]

Hi Håkon,

So I've updated my sample app to enable console logging and I've checked the "rare" reset reason behavior.

It looks like from time to time the reset reason is zero. I've even used the nrfx function to confirm that.

But apart from that, the main problem still persists. I'm not sure how to proceed further with that. Please advice.

Thanks - Mariusz

[Håkon Alseth]

Hi Mariusz,

 

Reset cause of 0 indicates a power on reset, which is expected when you are power cycling the nRF.

Q1: Which version of Segger JLink (https://www.segger.com/downloads/jlink/) are you using?

Q2: Can you try to power on/off via the pin header ("VDD current measure") instead? I suspect the boot-up process of the Segger IC (depending on firmware version on this one as well) will reset the DUT, and thus give a debug and pin reset upon boot.

Please note that you can get other sources set with pin reset in resetreas register, as per this errata:

https://docs.nordicsemi.com/bundle/errata_nRF54L15_Rev2/page/ERR/nRF54L15/Rev2/latest/anomaly_L15_48.html#anomaly_L15_48

 

Kind regards,

Håkon

[mkoclega]

Hi Håkon,

Håkon Alseth said:

Reset cause of 0 indicates a power on reset, which is expected when you are power cycling the nRF.

Oh, right. These mappings into Zephyr's generic reset cause codes are a bit misleading. I assumed I should expect RESET_POR.

Håkon Alseth said:

Q1: Which version of Segger JLink (https://www.segger.com/downloads/jlink/) are you using?

I'm using v8.66. I actually initially installed the latest one but the nRF Connect warned me it's not supported yet and may lead to issues, if I remember correctly.
Nevertheless is that even important when I run the DK without USB data connection and get the same behavior? I'd say it's rather the Segger firmware that may be causing that. Is there a way to update it?

Håkon Alseth said:

Q2: Can you try to power on/off via the pin header ("VDD current measure") instead?

Yes, that helps! It's tricky at the moment to test it with many iterations, because when the SoC uses literally no power during System OFF and the VDD:nRF voltage drops very slowly. Need to connect some load or modify the app to discharge it quickly. I'll play with that.

Håkon Alseth said:

Please note that you can get other sources set with pin reset in resetreas register, as per this errata:

Yep, I've noticed that in the errata. Planning to adjust my code eventually but for now it wasn't that importatant I guess.

Thanks - Mariusz

[mkoclega]

Hi Håkon,

 

mkoclega said:

Need to connect some load or modify the app to discharge it quickly. I'll play with that.

So I've connected a 10k resistor between VDD:nRF and GND. Now when I keep power cycling the SoC with the P6 header jumper, the bahavior is as expected. I get RESETREAS == 0 every time.

However it doesn't work then I power cycle with the switch (the resistor doesn't help here).

Thanks - Mariusz