Sounds wonderful. :-) Note that SRST isn't ONLY used in JTAG or SWD, AVR_ISP will also need control over SRST line, many other MCUs may need it too, because it's basic signal in MCUs. How about make SRST a "transport" and can generate a reset event. Then, Cortex-M3 target will need JTAG+SRST or SWD+SRST "transports". But problem will be that SRST and TRST will not be able to be handled in one command, because TRST belongs to JTAG. Compromise Maybe that JTAG/SWD can handle SRST and meanwhile there exists a SRST "transport".
Moreover, I think maybe more than one "transports" can be validated on one target. For example, "transport" for debug port and "transport" for trace port can be validated at the same time. 2010/3/13 David Brownell <[email protected]> > 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. > > -- Best Regards, SimonQian http://www.SimonQian.com
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
