Debugging TFM application on nrf9151

[odik]

I'm not able to debug any of example applications that uses non secure build. Non ns versions works fine. I have added CONFIG_TFM_CMAKE_BUILD_TYPE_RELWITHDEBINFO=y  to my prj.conf. Debugger connects but I'm not able to pause it, place breakpoints or checking any of program variables. I'm using nrf connect with vscode.

Thank you for your help.

[Benjamin]

Do you experience the same on a DK?

[Monkeytronics]

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! 

[Benjamin]

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

[Monkeytronics]

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?

[Benjamin]

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

Regards,
Benjamin