On Sat, May 30, 2009 at 10:36 PM, David Brownell <davi...@pacbell.net> wrote: > On Saturday 30 May 2009, Ųyvind Harboe wrote: >> >> So these are *targets* that don't need or want >> >> TRST? >> > >> > In the Atmel case, yes. >> > >> > In the TI case, no. TI boards often come with >> > both "TI-14" and "ARM-20" JTAG connectors. >> > So whether you have SRST depends on which kind >> > of JTAG adapter you use ... not the board, not >> > the CPU. >> >> How about using separate target/board config files to >> handle different connectors on a board? > > No, that's chaos. > > Notice that my "PROPOSAL 2" gave a completely clean > way to handle that: the *JTAG adapter* can veto the > use of a particular signal. So an adapter that talks > "TI-14" could say "disable_srst" ... and when it hooks > up to a board that's correctly setup for "srst_and_trst", > it will work just fine. > > Or in the AVR8 case, tha board might say "disable_trst" > then it won't matter what kind of jtag link is used. > > This would work well with a "disable_rtck" ... when > a board doesn't support it, it shouldn't be possible > to try using it even if the adapter does.
rtck is handled differently: if rtck is not supported, then setting rtck fails. The tcl code can catch this exception and deal with it. look at the tcl definition of jtag_rtck... Perhaps something similar for reset_config? The interface would make it fail if the combination isn't supported and then the target config script can try to deal with it? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
