MCUXpresso debug 2 targets concurrently - problem with breakpoints

[jgreen]

Hi, I'd like to report a problem I found with breakpoints when debugging 2 targets concurrently.

In my case I am debugging an I2C transfer between master and slave targets. I have a debug session running at the same time, for both master and slave hardware target. It's cool that Xpresso will support multiple concurrent debug sessions.

My issue is that Xpresso is unable to separate the breakpoints for context of a target - it appears to note them as file_name plus line number - but not which target.

Result is that when I restart a debug session for one target, it will attempt to set breakpoints of <ALL> targets. This causes a problem when I restart debugging for target#1 and it attempts to set breakpoint that was originally set for target#2 and the source file name for target#2 doesn't exist for target#1 (did I explain that in a way that can be understood!)

So I think breakpoint info stored by Xpresso should also include info about project as well as source file name and line number.

Regards

Jon 

[lpcxpresso_supp · Accepted solution]

I think the behavior you describe is the right one since we're talking about breakpoints set in a specific file and at a given line. Eclipse always tries to install all breakpoints listed in Breakpoints view in a new debug session. Any BP set in a file and on a given line, will have associated some properties, and amongst them there's the absolute file path. See the following screenshots.

So, the breakpoints are actually linked to a project by very simple means - file path and project location.

When you have two breakpoints like the ones below, set in two different projects, Eclipse will attempt to install both of them when starting a debug session on any project. However, only some of the breakpoints will be resolved based on the debug information found inside the elf files. Basically, if you'll inspect the debug dump (obtained with readelf), you'll see something like:

<e9d> DW_AT_name : (indirect string, offset: 0x117a): ../source/frdmkl26z_hello_world.c
<ea1> DW_AT_comp_dir : (indirect string, offset: 0x52f): C:\SomeFolder\MCUXpressoIDE_11.0.1_2563\workspace.5\frdmkl26z_demo_apps_hello_world_1\Debug

Based on the actual location of the source file on the host computer and based on the two descriptors found in the DWARF information, GDB decides whether a breakpoint can be installed or not in a given context. If breakpoint cannot be resolved, we'll see it being marked as pending:

info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> C:\\SomeFolder\\MCUXpressoIDE_11.0.1_2563\\workspace.5\\frdmk64f_hello_world_1\\source\\frdm64f_hello_world.c:37
3 breakpoint keep y 0x0000050e in main at ../source/frdmkl26z_hello_world.c:60

There's a filtering option available in Eclipse but this needs to be configured at debug time. This way, you can limit a given breakpoint to a given target but the configuration is not persistent for subsequent debug sessions.

Given the above mentioned comments, are there any side effects of current behavior in your use case? What isn't working in fact? It's not very clear from your description.

Greetings,
MCUXpresso IDE Support

[jgreen]

BTW, I now have more detail about this issue...

If I have a breakpoint set for target#1 and I start debugging target#2 then I get the dialog box shown below...

At this point I have 2 options...

1. Press 'Cancel' which will terminate debugging

2. Press 'OK' which just closes the dialog. The dialog then reopens if I try again to debug - therefore preventing me from running any code.

[lpcxpresso_supp]

Unfortunately, the error doesn't say much with regards to the actual root cause of the problem. Please attach the contents of the RedlinkServer console, the contents of the console ending with "Debug messages" and the GDB traces. Maybe we can figure out based on those what's causing the failure. Moreover, please check whether the redlinkserv process is still running when the error pops-up.

Greetings,
MCUXpresso IDE Support

[jgreen]

The reason I raised this issue was because when I tried to debug one of my targets I got a message saying something like: Cannot start debugger because breakpoints cannot be set - sorry I don't recall the exact wording.

As a result of that I had to delete the breakpoints of the unused target before debugger would run. This was rather annoying and did seem like a flaw that was worth reporting.

Since getting your reply I tried again and found it works well this time - exactly as you describe.

So I can only assume that Xpresso got into some state that prevented setting the breakpoints when debugging my multiple targets, and this was fixed by a restart.

As I said in my original posting... It's cool that Xpresso will support multiple concurrent debug sessions.

Thanks for your help - much appreciated.