Running MCUX 10.2.0 - and this time it's a completely fresh, unmodified install with no PEx or non-standard toolchain.
I'm debugging my USB descriptor handling code and set a breakpoint in USB_Desc_Valid_Configation(). (You can tell it's from a Freescale example because 'configuration' is misspelled. Along with 'composite', 'function', 'is', 'successful', 'received', 'supported', 'increase', 'interface'...) I forgot, however, that the function isn't actually referenced. Nor is the next function.
The result is that the breakpoint invisibly moves to an entirely different function further down. I understand that picking the next line that actually produces any code is typical, but shouldn't it be confined to a single function? And I seem to remember that CodeWarrior would visibly move the breakpoint marker to its actual location.
Scott
I have duplicated the behaviour you describe - and of course, this does raise an interesting question as to how a source line should ultimately be related to an address. For this question, CDT, the Compiler/Linker/Dwarf debug tables and GDB are involved.
However, the behaviour is that breakpoints set by double clicking within the edit view will be set to an address corresponding to the closest match to actual code. You can see within the Debugger console which particular breakpoint has been hit - if required. There are alternative options such as setting breakpoints within the IDE on particular functions etc.
You can also drop to the Debugger Console to directly set breakpoints on an address or on a function e.g.
break *0x2000
Breakpoint 6 at 0x2000
break *used_function
Breakpoint 7 at 0x8ac: file ../source/hello_world.c, line 86.
break *unused_function
Breakpoint 8 at 0x0 <<-- since this function doesn't get linked into the image
While we accept that this may not always be ideal, there is likely nothing we can do to change this behaviour.
Yours,
MCUXpresso IDE Support
Hi Scott,
Could you please take screenshots show your problem ?
mainly about "The result is that the breakpoint invisibly moves to an entirely different function further down. "
BR
TIC
Here is a simplified example. Note that the breakpoint is set in unused_function(), but the debugger stops on used_function() despite no breakpoint marker showing up there.
Scott
Hi Scott,
If place a breakpoint in the function that not called, the breakpoint will fall through to the nexet valid line.
Yes, that's exactly what I'm trying to illustrate here. I know what it's doing. But why? How could that ever be the intended behavior, having execution stop in an entirely unrelated function? It tells you nothing about the program flow and gives you no indication of which breakpoint actually caused the break.