MC56F84789 in a custom board, USB Multilink FX @ default connection speed. Regular breakpoints inserted as "hardware" checked in debug setup. Codewarrior 10.6 basic nodelocked activated licence.
Application size = 110kB -O0, 97kB -O1.
I've always had poor behaviour on the debugger in my application. It won't stop at particular breakpoints (skidding) and will stop every time around a for() loop if the breakpoint is near it on the outside. It may also stop at a seemingly random position in code, as well as stopping at a previous sessions's breakpoint even when "remove all" has been chosen to remove all breakpoints.
This has made developing the application painful at times, awkward at best and impossible on occasion.
Now the debugger has this morning refused to stop on any breakpoint, and every download displays the message "Breakpoint warning: Unable to set all the breakpoints requested. Some breakpoints will be disabled and will not stop the processor"
I've asked an FAE about this and received some feedback, namely that optimisation will hinder correct debugger operation. Well, yes, but now even -O0 won't work. The DSC compiler doesn't have an optimisation level for debug.
I know the code is working, as I get comms and data back from our PC side app. I can pause the debugger and see it's going through the main loop, but putting a breakpoint anywhere doesn't stop the processor. As per the warning really.
The application I'm developing has in the past few weeks been launched in a new product for my company. Any ideas / suggestions welcome.
The application on the DSC communicates to a PC over serial. The PC monitor application can reset the DSC with a serial command, this invokes a software reset. (a PESL function)
What I need to do is run a particular function on the custom board. This takes several minutes. I'm debugging this and want to capture a lot of variables. So, I start a debug session, capture variables, run the test, and capture variables again, to get a before and after picture. Then I want to reset the DSC, and capture variables again. This is where the debugger would not stop on a breakpoint once inserted. So, I could suspend the DSC application, and capture the variables. Then I ran the test, and then tried to insert a breakpoint. This locked up the PC application, because comms froze. (no data from the DSC). But, the debugger said the DSC application was running. However, I could not pause the debugger, as that option disappeared from Eclipse.
I needed to run this test three times but the debugger crashes out / goes unstable after the first time.
Any suggestions welcome.
Debugging is back. I restarted CodeWarrior and tried insert breakpoints as regular. Regular breakpoints work, software breakpoints work, hardware breakpoints don't. I was advised to use the hardware option previously due to erratic operation. Other points such as skidding and "ghost" breakpoints still exist.