Trace32 Breakpoints

Software breakpoints do modifications on your code to "handle" the breakpoint and so require writable memory. So indeed, if your code is in flash or in a ROM, you can't set software breakpoints.

On another hand, you have no limitation on the number of software breakpoint whereas hardware breakpoint are limited to 2 or 3 (if I remember well and may be more if you use JTAG/ETM instead of just JTAG).

Regards, Guillaume

you're right.

when code in flash/rom => onchip / hardware implemented breakpoints

when code in ram => both onchip and software breakpoints are possible.

For data break points AFAIK, you can use only onchip/hardware breakpoints..

BTW: you didn't mention the CPU family you are using.

Although I don't know the capabilities of Trace32, your assumption is not generally right. One can use hardware breakpoints for code in RAM and "software breakpoints" in Flash - maybe Trace32 doesn't support the latter, but iSYSTEM winIDEA does.

I dislike software breakpoints in Flash since Flash is programmed twice on each breakpoint hit. This causes delays and Flash wearout. Well, the Coldfire I'm using should survive 100000 cycles at room temperature, so unless I have a breakpoint with some counting condition, this will last long enough.

Oliver

Why twice on hit ? I would think they will simulate the breakpoint instruction, so unless you remove the breakpoint, they won´t reprogram the flash.

I'm not sure but I don't believe that every debugger on every target simulates the instruction.

Oliver

If it supports breakpoints in flash I am pretty sure. If not simulate then they will use some RAM to execute this patched op-code there and then give back control where it left.

Or just re-direct it to RAM.

Robert