NRF52832 Jlink Debugging Zephyr application is impossible.

[Zings]

I have inherited a NRF52832 design, it uses Zephyr and I am using the NRF52 DK to debug the design using the SWDIO and SWDCLK.
The board flashes correctly and I can single step the debugger all the way through the Zephyr initialisation code until it wants to jump to the main thread.

This is when the debugger loses connection and cannot recover.

The code I am using uses the SAADC and a timer to sample analog inputs. I think that the SAADC and timer is somehow interfering the the debugger by flooding the interrupt.
I assume that jumping to the main thread enables all the interrupts so the debugger works until interrupts get enabled.

The program will run without the debugger so I have added a check to see what interrupts are enabled when main starts.

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 dont understand why SAADC is enabled, it should be initialised after main starts, the saadc configuration is set and the timer set for the sample rate.


Can anyone help or offer ideas to get the debugger working?

NRF52832
NRF52DK
Windows 11
NRF Connect For Desktop 2.5.0
ncs v2.4.2

[Einar Thorsrud]

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)?

[Zings]

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?

[Einar Thorsrud]

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.

[Zings]

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 */
  };
};

[Zings]

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?