It seems to me that the JLink-Ultra offers a lot more than the ULink-Pro but is this always going to be the case?
I pay annually for support for Keil, so if I buy a ULink-Pro that all comes with in that support, but if I buy the JLink I have to pay support for that in addition.
Will the ULink-Pro be enhanced to the level of the JLink I.E. unlimited Flash break points, 25MHz JTag etc, in the near future.
Does any one have both that Jlink-Ultra and ULink-Pro? pro's, cons's?
unlimited Flash break points
Isn't this a limitation of the underlaying hardware...?
Up to a point I think you are right, however in principle its much like treating flash as you would ram but with a few more hoops to jump through.
www.segger.com/.../jlink-flash-breakpoints.html
"Isn't this a limitation of the underlaying hardware...?"
Depends.
You basically have four methods to implement the break points in flash, but most target chips can't support all four.
The best way is when you use the hardware in the chip where there is a debug cell with address match. Obviously, the number of breakpoints are very limited and depends on the processor.
The (potential) second best way is when the processor can trace out the addresses in real time, allowing the external debugger hardware to perform address matches. In this case, it's the external hardware that will have a limitation on the maximum number of addresses it can concurrently perform matches on. One problem here is that even if the processor have trace support, the trace output may contain delays so when the trace tells about address x, the processor may already have performed that instruction.
The general backup plan is to reprogram the flash memory and replace bytes in the flash with other instructions so you get some form of SWI or similar. This allows you an unlimited number of breakpoints but generates lots of wear on the flash memory since the flash pages needs to be reprogrammed to set/clear breakpoints.
Some processors can remap RAM above the flash, allowing a fourth method, also supporting huge number of breakpoints but at the cost of losing as much RAM as is needed to remap the flash regions. Obviously, the target chip needs some form of MMU for this.
http://www.keil.com/ulink/cmp.asp
As you can see, CM3 devices inherently support up to 8 ROM breakpoints. Is it nice to have an unlimited number? Sure, but not THAT dramatic anymore...
When needing large number of breakpoints, I often add dummy calls to a helper function, allowing me to set a breakpoint on this function. The stack will tell me where I came from. And clearing this single breakpoint is a quick way to get the program to zoom ahead again. Most of the time, the code isn't time critical enough that it hurts to have an extra call/return added here and there.
And most of the time, that dummy function isn't even expected to be called, i.e. the call is only made if the software sees an unexpected event.
Yes, I have something similar down here!