On Fri, May 18, 2012 at 2:18 AM, Bill Traynor <[email protected]> wrote: > I'm receiving Error: interface can't tri-state 'nSRST' while testing the new > ftdi driver with openocd from git, flyswatter2 JTAG, and PandaBoard-ES. I > built this OpenOCD today from git using the following patches: > git fetch http://openocd.zylin.com/openocd refs/changes/35/535/3 && git > checkout FETCH_HEAD > > and build: > sudo ./configure --enable-maintainer-mode --disable-werror --enable-ftdi > > Start up command is: > sudo ./openocd -f ../tcl/interface/ftdi/flyswatter2.cfg -f > ../tcl/board/ti_pandaboard_es.cfg > > result: > > Open On-Chip Debugger 0.6.0-dev-00557-g61d38c5 (2012-05-17-17:08) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.sourceforge.net/doc/doxygen/bugs.html > Info : only one transport option; autoselect 'jtag' > RCLK - adaptive > Using dbgbase = 0x80000000 > force hard breakpoints > trst_only separate trst_push_pull > Info : RCLK (adaptive clock speed) > Error: interface can't tri-state 'nSRST' > > I see that the new ftdi/interface/flyswatter2.cfg contains the following 4 > new lines: > > ftdi_layout_init 0x0818 0x017b > ftdi_layout_signal nTRST -data 0x0010 > ftdi_layout_signal nSRST -data 0x0020 > ftdi_layout_signal LED -data 0x0400
This is because reset_config selects srst_open_drain (or leaves it as the default), while the flyswatter2 only has a push-pull output for nSRST, at least according to the configuration file. I wrote the flyswatter2.cfg based on what was implemented in the old ft2232 driver. If the adapter really can tristate nSRST, an -oe or -noe (depending on polarity) specification should be added to "ftdi_layout_signal nSRST". Are there any schematics available for the flyswatter2? The signal definition in the adapers' config files tell the new ftdi driver what the adapter supports. The reset_config mechanism in OpenOCD is totally oblivious to what the capabilities of the adapter/driver(/target) are. This is one of many similar architectural flaws in OpenOCD that needs fixing sooner or later. As of now, the user must make sure that the reset_config matches what the adapter can provide. Edit: I see now that your reset_config has trst_only, so nSRST shouldn't get asserted at all. Maybe there's a logic error in my code for that case, I'll take a look. You could try adding srst (w/ push-pull) to reset_config, or comment out the nSRST line in flyswatter2.cfg if you must avoid hardware reset. /Andreas ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
