On Wednesday 03 March 2010, David Brownell wrote:
> Meanwhile, I'll draft something on transport modes (as they
> apply to "debug adapters" and targets. While the initial
> focus will of course be JTAG vs SWD, I'll keep in mind that
> others might come along (especially for "program" mode).
OK, part of it (preliminary patches to come later):
* There will be a "struct transport" with a name and various
methods. Inside OpenOCD there will be a list of registered
transports, and one transport that's active for the current
session.
* a "transport_list command will display what transports the
current OpenOCD understands ... initially "jtag", soon also "swd".
- "Programmer" transports can be defined, like "UART", which
I imagine could someday work like
* Cortex-M3 with "lm3s" variant could use the Stellaris
bootloader packet formats
* Cortex-M3 with "lpc17xx" variant could use NXP's
bootloader ISP programming scheme
* ... some chips (like AVR8) have SPI variants too
* ... etc
* Debug adapters will be associated with one or more transport
names. I'm thinking they'd normally be declared by the debug
adapter driver, but there will also be an option for doing it
via Tcl scripts (in case of e.g. needing hardware jumpering).
We'll have lot of JTAG-only adapters, also JTAG-and-SWD.
Versaloon, BusPirate, and Signalyzer can do many more...
* To select between transport options from the debug adapters,
"transport select swd" (or jtag, etc) ... no args will
report the current transport (for conditional scripts)
Except after "transport_select jtag", the JTAG script commands
will not be available.
* We'd try to make JTAG-only debug adapters behave prettty much
the way they do today (no extra config needed)
* For the Cortex-M parts which have two transport options, I'm
thinking we'd replace "jtag newtap" with a new declaration that
would work with SWD not just JTAG ... so target config files would
easily work with either transport ... maybe it'd look like "dap new ..."
We may want a new type for what's now "target->tap" ...
We'll likely need a command to manipulate SRST by itself, and which can
work with both JTAG and SWD sessions. Otherwise I can imagine some of
the target event handlers breaking. Ditto updating interface clocks.
* Individual targets will have "target create" options to cope with
issues like LPC13xx Cortex-M3 cores being SWD-only. I'm thinking
"target create -transport swd ..." will mean "-chain-position X" is
not allowed, and JTAG-only sessions won't work with that target.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
