Hello, With the plenitude of low-cost development boards (LCB in following text) on the market (proverbial Arduino is an example *1), I find it surprising that none of them is supported in OpenOCD mainline.
That shows fragmentation among "maker" community which deals with such low-cost boards, "professional" community which uses JTAG daily and members of which likely have dedicated JTAG adapters, and "software" community who could be offered easy curve to start JTAG usage using an LCB, but instead keeps asking why ARM can't output early debug info via serial, like x86 does. So, LCBs will let "maker" community do something more useful than blinking LEDs, and let "software" guys easy way to know how to do their stuff right. Speaking of LCB, what meant is "something which almost everyone already has". But of course, everyone would have different board, so supporting just one or two, or striving to support as much as possible different ones on OpenOCD level doesn't make sense. Instead, OOCD should define a protocol which would be easy to implement on any LCB. Then, any LCB for which such simple firmware is written, will be automagically supported (note: it's assumed that LCB communicates with a host using UART protocol (likely transparently wrapped in USB)). Requirements for such protocol may be: 1. Allows just setting/getting state of signals, so bitbanging is handled by host (OpenOCD). 2. Doesn't support pipelined or duplex communication, instead following half-duplex request-immediate-response protocol for all commands - to allow use with bitbanging UART for host communication (so once again, we target to support all MCUs in LCB, from an ATtiny and similar). 3. Tries to stay within ASCII to facilitate human introspection and debugging. 4. Doesn't require configuration and "just works" (frequency limited by host UART channel, signals are configured during firmware compilation). Of course, such a protocol will be damn slow. That's OK for intended purpose - to let people get easy acquainted with JTAG. Then, they can either buy professional adapter, build open-hardware one, or... implement more efficient protocol. This effort should anticipate the last choice, and specify that there're different "levels" of protocol, with one outlined above being "level 0". So, I spent last couple of days prototyping implementation of such protocol, which I dubbed SimpleJTAG. Definition I currently have is: #define CMD_WRITE_TCK_TMS_TDI '0' // +7 #define BIT_TCK 4 #define BIT_TMS 2 #define BIT_TDI 1 #define CMD_WRITE_TMS '8' // +1 #define CMD_WRITE_TCK ' ' // +1 #define CMD_READ_TDO 'o' #define CMD_READ_TMS 'd' // aka SWDIO #define CMD_BLINK_ON 'B' #define CMD_BLINK_OFF 'b' #define RESP_ACK '+' #define RESP_NACK '-' #define RESP_VAL '0' I'd appreciate feedback on problem domain specified, approach, and actual protocol details. *1 Granted, Arduino is bad example of a board for JTAG due to its 5V supply voltage, so by "Arduino" I mean "well-engineered Arduino variant supporting contemporary voltage". Thanks, Paul mailto:[email protected] ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
