Debugging two custom images in one debug session

RE: Debugging two custom images in one debug session

Susheel Nuguru — Fri, 11 Mar 2022 07:59:08 GMT

I think what you are seeing is the SES feature. There are settings in the SES where you can set the Debugger to steal the RTT logs and display them to the SES debug terminal instead of any other terminal. I do no think this is related to your solution but the way the SES and RTT viewer are trying to get a lock on the prints.

[quote user="kcl74"]If I find some time I'll recreate the projects so you can replicate it on your end.[/quote]

Yes please do that, it will be helpful for me to understand more on this issue.

RE: Debugging two custom images in one debug session

kcl74 — Tue, 08 Mar 2022 17:13:21 GMT

This is a custom board that has nothing connected to it other than a JLink Base unit. Whatever is getting printed to a terminal is through the means of the SWIO pin connected to the JLink unit.

To be clear, the linked library has 0 dependency on nRF5 SDK/SoftDevice. It is a native C library that is compiled in SES (using gcc). It's just calling "printf", it is not calling any sort of NRF_LOG or anything of the sort because it has no idea nRF platform exists.

The linked library is also not hitting a hardfault because the second I connect my JLink unit when the application is hanging, the chip spits out whatever data is in the buffer used for printf, presumably because the JLink CLK pin clocks that data out, and then the application continues to run from where it left off--it doesn't reset, it isn't stuck in hardfault handler, it resumes.

If I find some time I'll recreate the projects so you can replicate it on your end.

RE: Debugging two custom images in one debug session

Susheel Nuguru — Thu, 03 Mar 2022 12:25:54 GMT

[quote user="kcl74"]but the printf calls from the linked library end up only in the Debug Terminal in SES. [/quote]

It looks like the prints from the precompiled library are redirected to serial port and the application is configured to redirect the logs to the RTT.

It looks like there is a bug in the way logs are handled in the linked library. It most likely is causing a stack overflow (if you are using buffers) and eventually an hardfault.

RE: Debugging two custom images in one debug session

kcl74 — Tue, 01 Mar 2022 23:09:50 GMT

So I have a pre compiled library that I'm using which calls printf. It is intended to be a portable C library. I build the library with SES.

My application that links against the library is my nRF52832 nRF5 SDK project. It does not utilize nRF logging module. It does use FreeRTOS. The printing task also calls printf and nothing else.

When I run the project in SES I can see the output from the printf statements in the Debug Terminal.

It gets more interesting...

When I start debugging and hit breakpoint at main(), if I open J-Link RTT Viewer and connect, then continue running my code in SES, the printfs that are called from the task is output to RTT Viewer, but the printf calls from the linked library end up only in the Debug Terminal in SES. No printf out from the task is shown in SES Debug Terminal and no printf output from the linked library is shown in the RTT Viewer.

The only thing connected between my PC and my board is Vref, Gnd, IO, CLK running into my J-Link Base unit.

Today I found that the printf in my linked library caused my nRF application to hang when I didn't have a debugger attached. When I attached the debugger via SES, the first thing I saw was the output from the printf in the linked library, and then the application ran without issues. I'm not sure why that happens. I removed the printf statements from the linked library and the application stopped hanging.

RE: Debugging two custom images in one debug session

Susheel Nuguru — Mon, 28 Feb 2022 14:01:58 GMT

If both the applications are using the same UART instance then probably the second application re-initialization of UART registers might be causing some conflicts. Try to use two different UART instances for two application logging. Also check your preprocessor defines to see if there is any way that might cause the logs to be not included into the build. I do not see any other reason for the two applications to have the logs work correctly if they are using different RAM spaces.

RE: Debugging two custom images in one debug session

kcl74 — Mon, 28 Feb 2022 13:11:10 GMT

Then it's UART because the applications are only using printf. No logging module or anything fancy.

I am still hitting breakpoints in both applications. I'm specifying to use the .elf files of the additional application when I load additional information.

I can also jump between the two applications and see the different BLE service UUIDs advertise. If i find time I'll try to create project that reproduces the issue.

RE: Debugging two custom images in one debug session

Susheel Nuguru — Mon, 28 Feb 2022 10:07:58 GMT

Hi Kevin,

Which print statements are you using? The normal printf in our SDK redirect the logs to the UART and not RTT.

[quote user=""]What do I have to do differently so I can see the printf output from both applications? [/quote]

I do not have any information on both of your application contents to say why your second application is not showing your logs.

Can you give more information on what kind of logs have you enabled? and how do you check if your second application is starting at all?