Debugging TFM application on nrf9151

RE: Debugging TFM application on nrf9151

Benjamin — Fri, 21 Nov 2025 12:08:33 GMT

Hi,
We can have a look at your schematics if you'd like. Feel free to submit a new private ticket.

Regards,
Benjamin

RE: Debugging TFM application on nrf9151

Monkeytronics — Thu, 20 Nov 2025 23:19:59 GMT

Similar behaviour in both cases - although debugger gets stuck more often with TF-M enabled.

I've looked at teh DK schematics and the debugger should work the same for my board as for DK? The only difference is the SWO is connected to pin 0.22 on the DK, which I have not done on my custom board. But it's not being allocated to a UART TX pin (for example) in the DK device tree so I can't see any relevance there.

Developing without logging is a real limitation. Do I need to buy a different piece of kit, or am I missing something here?

RE: Debugging TFM application on nrf9151

Benjamin — Thu, 20 Nov 2025 15:19:40 GMT

Thanks for the additional details and apologies for the slow reply. Just to confirm, does everything work as expected if you do these tests without building with TF-M?

Regards,
Benjamin

RE: Debugging TFM application on nrf9151

Monkeytronics — Fri, 14 Nov 2025 06:14:21 GMT

Good question! I did an experiment to explore. I created a blinky application as a sandpit. Then I created a build configuration for the nRF9151_DK and one for my custom board (adding in SPI, PWM, I2C nodes).

1. Everything worked perfectly on the DK - debugging logs and stepping through code.

2. With the exact same setup, I could step through the debugger on the Custom board (external debugger from DK) but I could not get any console logs of any sort, either through COM port or RTT. I tried printk & logger. Nothing.

3. Custom board, but with custom board files = random behaviour! Including exactly what OP describes. I isolated the problem to my SPI flash memory device tree node, which is (apparently) malformed. So, even though I'm only running a blinky app, nRF Connect is clearly compiling and running some initialisation code for the SPI peripheral. And getting stuck. Why this only takes effect with debugging enabled - No idea! But I need to fix the device tree code! It's a pity there isn't some sort of tree-shaking in place to avoid this - if only because it's so counterintuitive to fault find...

TLDR -

1. External debugging doesn't appear capable of console logging. Do I need to get a dedicated debugging dongle???

2. Errors in device tree can break debugging sessions even if peripheral isn't used!

RE: Debugging TFM application on nrf9151

Benjamin — Tue, 11 Nov 2025 22:22:20 GMT

Do you experience the same on a DK?

RE: Debugging TFM application on nrf9151

Monkeytronics — Tue, 11 Nov 2025 07:04:02 GMT

Hi, just to bump this thread, because my experience is the same as odik With an _ns application, I don't seem to be able to debug anything at all. When I run the debugger, it gets stuck either inside cmsis_gcc_m.h or at reset_handler(). If I continue, it never triggers again, and never reaches my main (which has breakpoints waiting for it). I've tried all the suggestions I could unearth from this forum (CONFIG settings; -exec mon reset ... ) , but nothing appears to work.

I'm working on a recent install of the nRF Connect environment in VS Code. My application is running on an nRF9151 on a custom board, and I'm using my 9151 DK as a programmer with the DEBUG OUT port (if that is relevant).

If I just flash the code, it seems to work fine by the way. I can capture I2C transfers on my oscilloscope and fiddle with PWM outputs.

RE: Debugging TFM application on nrf9151

Benjamin — Tue, 01 Jul 2025 11:11:07 GMT

Hi,
There was someone with a similar issue you could check out. In short you could try to set debug level in the .config file under build/{app_name}/zephyr/

This exercise is also great to check if you are new to debugging in NCS on VSCode.

The CONFIG_TFM_CMAKE_BUILD_TYPE_RELWITHDEBINFO symbol is for debugging the code in the Secure Processing Environment. Applications are running in the Non-secure Processing Environment and this Kconfig symbol should not matter.