Hi folks.  I'm working on adding ITM trace support for the Atmel EDBG
(CMSIS-DAP) dongles and would like to discuss how tracing should be
implemented in general.  Right now we have only one ITM trace
implementation (in the stlinkv2 HLA driver) and that's done in the target
polling method as well as a timer callback.

Tracing is available on many targets, not just ARM Cortex-M via SWD, but of
course the implementation differs quite a bit (I've learned of
implementations on PowerPC, MIPS, etc).  I think the simplest solution
would be to hook in to or near target_poll() in src/target/target.c and
then if:
1. tracing is available for the target and,
2. tracing is supported (by the underlying adapter) and,
3. tracing is enabled
call the appropriate handler.  Typically this would just retrieve all trace
data and send it somewhere.

That said, the configuration (in TCL) would need to be more target-specific
or maybe even interface specific.  For Cortex-M, one would generally just
need to specify a rate either for configuring the interface and target
hardware directly or for setting some interface-specific clock rates
(stlink can't handle anything above 2MHz for example while Atmel is more
flexible).  Then for ARM Cortex-M there are the actual channels and so on.

If a target.c-level feature is too general, would hooking into the cortex_m
stuff be more appropriate (and then we can wait until someone wants to
implement something for a different CPU target)?

How should target vs. interface settings be handled?

Thanks,

  -Andrey
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to