Debugging two custom images in one debug session

[kcl74]

I have two custom images that I flash to my chip (nRF52832, SDK v16.0.0, SEGGER Embedded Studio).  Application 1 is located at 0x26000 Application 2 is located at 0x45000.  Application 1 always runs at start up and depending on certain conditions, it will jump to Application 2.

Both application images are generated from the same SES project.  I have two build configurations and each build configuration has its own set of preprocessor definitions that will affect what gets compiled into the applications.  As a side note, I'm using FreeRTOS and have "print" task whose sole responsibility is to print debug messages which show up in the Debug Terminal, I believe this is the JLink RTT output?  I am not using the nRF logging module.  

I modified my build configurations to load the other application to the chip when I start a debugging session.  So if my active project is set to Application 1, when I start debugging it also loads the SoftDevice and Application 2.  When Application 2 is set to active project and start debugging is also loads SoftDevice and Application 1.

Depending on what build configuration is set as active, I only see the print statements in the Debug Terminal for that application despite the fact I can debug/hit breakpoints for both applications.

What do I have to do differently so I can see the printf output from both applications?  

[Susheel Nuguru]

Hi Kevin,

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

What do I have to do differently so I can see the printf output from both applications?  

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?

[kcl74]

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.

[Susheel Nuguru]

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.

[kcl74]

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.

[Susheel Nuguru]

kcl74 said:

but the printf calls from the linked library end up only in the Debug Terminal in SES.

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.

[kcl74]

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.

[Susheel Nuguru]

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.

kcl74 said:

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

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