[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

[Håkon Alseth]

Hi,

 

I tested your firmware, and consistently see that LED0 flashes for a short period of time, repeated every 5 seconds. As far as I can tell, this is the expected behaviour.

- the code resets immediately after going to System OFF with debugger reset cause (RESET_DEBUG) - this one is the most common,

Do you have a RTT session, or terminal running in the background, which is continuously trying to re-attach?

 

Kind regards,

Håkon

[mkoclega]

Hi Håkon,

Yes, this is the expected behavior - single flash of LED0 and going to System Off for 5 secs (with GRTC wakeup), and then repeat.

No I didn't have any connection as far as I was aware.
To be perfectly sure, I just powered the DK from a regular Samsung USB wall charger (a quite simple one, I think it doesn't support any advanced modes but 5V/2A via USB-A).

The behavior stays the same. I recorded a short video showing it. I put it in "vid" folder on my GitHub repo. You have to download it because it's too big to be displayed on the page (33 MB), sorry for that.

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

[Håkon Alseth]

Hi Mariusz,

 

mkoclega said:

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.

This is great to hear!

mkoclega said:

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

I believe that boot-up timing has a great impact on this, especially when you are power cycling using the main switch, as this will also cause a re-enumeration of the jlink device and the DK as a whole. I would suggest only power cycling the nRF and not the board as a whole.

 

Kind regards,

Håkon

 

[mkoclega]

Thanks for your support.

I think this issue should still be adressed by e.g. HW or Segger firmware fix.

A program that has little to do and goes to system off immediately may be quite common use case for a ultra-low power SoC. I guess people buy them for that and for solid BLE support.

I guess maybe the Segger FW tries to talk to nRF after that FW starts and in my case the nRF is already in system off sometimes, so the debugger is resetting it thinking it hasn't initialized properly or something.

I agree there's a workaround (with the P6 jumper) but do note how much time we both had to spend to discover that.

Thanks - Mariusz

[Håkon Alseth]

Hi,

 

I agree that in this test case, the behaviour is unfortunate and misleading towards what you expected would occur.

But, please keep in mind that you want to isolate the nRF, and not power on/off the board as a whole.

mkoclega said:

I guess maybe the Segger FW tries to talk to nRF after that FW starts and in my case the nRF is already in system off sometimes, so the debugger is resetting it thinking it hasn't initialized properly or something.

It is a bit more complex, as the SEGGER IC has several debug ports it can select, based on which signals are set/active. You can debug out externally, as well as the nRF in the DK itself, and you also have a check for external debug in.

  

Kind regards,

Håkon

[mkoclega]

Hi Håkon,

I understand, thanks again for your support.

Best regards - Mariusz

[Håkon Alseth]

Hi Mariusz,

 

I am always happy to help out. I hope you have a wonderful day!

 

Kind regards,

Håkon