NRF52832 Jlink Debugging Zephyr application is impossible.

RE: NRF52832 Jlink Debugging Zephyr application is impossible.

Zings — Wed, 29 Oct 2025 06:43:10 GMT

Thanks Einar,

I think I have found the answer. We drive LEDS on the PWM outputs. The dts file configures the pwm outputs with nordic,invert.

ChatGPT:-

If adding nordic,invert caused the debugger to drop, that’s often because:

All pins went active at init (due to inverted logic) and dumped current into LEDs/FETs → brownout → reset.
When the driver released the PWM, the “inverted idle” held pins in an unexpected state.

I have removed nordic,invert and the debugger now runs into main and stops, single steps etc.

RE: NRF52832 Jlink Debugging Zephyr application is impossible.

Einar Thorsrud — Tue, 28 Oct 2025 14:04:23 GMT

Hi,

Can you share some information on your custom board? Particularily, if it has the optional 32.768 kHz oscillator and the optional DCDC inductors in place? The DK board files enabled both DCDC and LFXO and if your custom board files do too, tha tcould be a problem (which we see quite often).

To disable the DCDC add CONFIG_BOARD_ENABLE_DCDC=n (or even better, don't set it to y in the board fiels if the inductors are missing). To use LFRC instaed of LFXO, use CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y.

RE: NRF52832 Jlink Debugging Zephyr application is impossible.

Zings — Tue, 28 Oct 2025 05:05:03 GMT

Update - I tried the version built for our hardware on the dev kit and it works with Ozone debugger no problems. So it appears that there is something configured in our board dts file that causes our hardware not to be debuggable. Any ideas?

RE: NRF52832 Jlink Debugging Zephyr application is impossible.

Zings — Tue, 28 Oct 2025 04:51:52 GMT

Thanks Einar,

I built the Zephyr samples\basic\blinky_pwm as our board is configured with a pwm led. I built
west build -p always -b nrf52dk_nrf52832 "%ZEPHYR_BASE%\samples\basic\blinky_pwm"

and also a version for our hardware. The nrf52dk worked perfectly with the Ozone debugger. I then tried the same file in our hardware (fortunately there is a led on the right gpio) and it worked with the debugger too. Then I built blinky_pwm with our project board configuration and the dying behaviour returns. I can stop the code after main has started and then in a couple of seconds a pop up appears with "Failed to read target status. Abort Debug Session?"

In order to build it with my board config I needed to add
"CONFIG_PINCTRL=y " to prj.conf
add a file app.overlay to blinky_pwm folder.

/ {
/* A logical PWM LED node the sample will use */
pwmleds {
compatible = "pwm-leds";
pwm_led0: pwm_led_0 {
/* controller, channel, period, flags */
pwms = <&pwm0 0 PWM_MSEC(20) PWM_POLARITY_NORMAL>;
label = "PWM_LED0";
};
};

aliases {
pwm-led0 = &pwm_led0;
};
};

//* app.overlay */
&pwm0 {
status = "okay";
pinctrl-0 = <&pwm0_default_custom>;
pinctrl-1 = <&pwm0_sleep_custom>;
pinctrl-names = "default", "sleep";
};

&pinctrl {
pwm0_default_custom: pwm0_default_custom {
group1 { psels = <NRF_PSEL(PWM_OUT0, 0, 17)>; };
};
pwm0_sleep_custom: pwm0_sleep_custom {
group1 { psels = <NRF_PSEL(PWM_OUT0, 0, 17)>; };
/* optional low-power props */
};
};

RE: NRF52832 Jlink Debugging Zephyr application is impossible.

Einar Thorsrud — Fri, 24 Oct 2025 14:11:47 GMT

Hi,

Interrupts itself should not cause problems for debugging. If the problem is debug related, then I suggest taking a step back and starting there, as digging down into interrupts may not be relevant for the issue you are attempting to solve.

Can you explain in a bit more detail the debug issue and what you do? Also, just to get a base line, do you have a development kit and are you able to debug the blinky sample on that? This could help us establish if the tools on your computer work properly. If so, the next step would be if you can explain in more detail how you debug your custom board and application and more on how it fails.

RE: NRF52832 Jlink Debugging Zephyr application is impossible.

Zings — Fri, 24 Oct 2025 04:28:27 GMT

Thanks Einar,

I appreciate the help, I have just picked up Zephyr and NRF52832 and trying to get my head around all the moving pieces.

I checked what interrupts were enabled, by adding code just after main and ran it without the
debugger.

00> *** Booting Zephyr OS build v3.3.99-ncs1-2 ***
00> == IRQs enabled right after boot ==
00> 0 POWER_CLOCK en=1 pend=0 act=0 prio=2
00> 6 GPIOTE en=1 pend=0 act=0 prio=6
00> 7 SAADC en=1 pend=0 act=0 prio=2
00> 17 RTC1 en=1 pend=0 act=0 prio=2

I managed to turn off SAADC interrupts and debugging still dies when main is called, so I think SAADC is off the hook now. It was my prime suspect as it is triggered by a timer, so the potential for interrupts to happen before the main code starts was possible.

I asked ChatGPT about the remaining interrupts.

POWER_CLOCK en=1 prio=2 ← clock/power driver (expected)
GPIOTE en=1 prio=6 ← gpio-keys/input driver
RTC1 en=1 prio=2 ← Zephyr system timer (always on)

So I tried to disable GPIOTE but cannot. Would GPIOTE interrupts cause J-Link debugger to die? The hardware is configured to use a timer at 1kHz to trigger the SAADC, would having 1kHz of interrupts possibly "unexpected interrupts" cause a problem for J-Link?

RE: NRF52832 Jlink Debugging Zephyr application is impossible.

Einar Thorsrud — Mon, 20 Oct 2025 13:16:22 GMT

Hi,

If you are using the Zephyr ADC driver, the ADC itself is initialized before the main thread runs (you can see here it is POST_KERNEL).

Have you confirmed that it is ADC interrupts that is the problem (for instance, this does not happen if the ADC is not enabled)?