On Wednesday 11 November 2009, Øyvind Harboe wrote: > I must admit I have not read up on the embedded trace capability, > much, but one of the things that I've heard it can do is to > set a breakpoint and then capture the PC for N instructions > going forward.
Depends on what you have hooked up to the trace port. Best case for current OpenOCD is ETB support, in which case it's not "N instructions" but "N words of trace data". (ETB is the trace buffer, with a few Kwords of data.) That's best for now because it's just a case of how to make the current code work, and since there's a lot of ARM9 (mostly -- but also some ARM11) hardware out there in users' hands. Once it's somewhat usable, then users can give feedback about what's needed/wanted. (Cortex-M3 tracing is quite a ways out yet. It needs the SWD support first. And the model there will be somewhat different, since apps can use ITM to feed info to the trace data stream, while that trimmed-down ETM is optional...) > The trick is how to present that in a GUI.... Actually, the trick is to get it to behave properly first, on various chips which support tracing! There are several steps I see. First verify that ETM works; it seems to, but with bad ETB hookup it's hard to know. Second is making sure it hooks up to ETB properly; today it shuts down shortly after startup. Third is making sure that the trace data is properly recovered and interpreted. Once that works, things like GUIs can start to matter. There are vendor products which do that, and their models are worth examining. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
