On Feb 6, 2009, at 11:55 AM, Martin Haeberli wrote:
Rick, I am runningversionOpen On-Chip Debugger 1.0 (2008-11-05-01:04) svn:1135 Perhaps I should somehow update to a more recent release?
You will probably want to either update to the 0.1.0 release or to the current SVN trunk.
I took your suggestion and started with a config file that doesn't create a target or a jtag tap.However, in my version, irscan and drscan both require a "device" argument.
Sorry, you will need to define a JTAG tap, but the configuration won't matter too much. Since OpenOCD will think it is the first tap in the chain, the drscan command will not try to pad the sequence clocked out to the chain.
so, I tried drscan (failed) drscan 0 32 1 "all devices in bypass" is the response help says drscan wants three arguments: <device> <numbits> <value> irscan 0 1 jtag device number 0 not defined connection to host lost I still get: "C:\Program Files\OpenOCD>openocd Open On-Chip Debugger 1.0 (2008-11-05-01:04) svn:1135 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $Error: JTAG communication failure, check connection, JTAG interface, target power etc. Error: trying to validate configured JTAG chain anyway... Warning:no gdb ports allocated as no target has been specified Warning:no tcl port specified, using default port 6666" While I have no particular reason to suspect the Signalyzer, mine is new, and I have no particular reason to trust it, either. So, I may try it with another device (the MAKE controller) to see if I can get it to work with that...; if that works, at least we know the Signalyzer is good.
Well, the error message indicates a JTAG hardware failure. It could be the dongle, the cable, or the target board.
Thanks, Martin ----On Fri, Feb 6, 2009 at 10:21 AM, Rick Altherr <kc8...@kc8apf.net> wrote:On Feb 6, 2009, at 9:01 AM, Martin Haeberli wrote:Rick, Thanks for your speedy response! The device under test proper does seem to work well enough with EJTAG to the extent that the USBJTAGNThack from www.usbjtag.com can talk to its CFI flash, get data from the flash, and reset it, as well as somehow talk to the internal boot ROMon the embedded M4kc core to the point where it can read it. Of course, I want to go further and do a little bit of debugging...One of the problems is that I don't have a board-level schematic, so Idon't know the order of the chips on the scan chain, nor do I have a .bsdl for the embedded cable modem controller chip. It would be nice to figure out how to do discovery of the scan chain order by hand.That's not an easy feat. If you start with a config file that doesn't create a target or jtag tap, you can use the 'irscan' and 'drscan' commands to manually run JTAG scans. On reset, a JTAG tap will default to the IDCODE IR. A 'drscan' as the first operation should return the IDCODE values for all the devices on a chain. While it isn't guaranteed, IDCODEs tend to have 32-bit data values. So, if you do a reset and a drscan of various multiples of 32, you should be able to determine the number of devices in the chain. It will also give you the IDCODEs so you can see if someone has a config file for a different JTAG device (BDI, etc) or if you can find documentationonline.Your main problem is that the IR length for each device on the chain is unknown. There doesn't tend to be a standard for that. You can figure out the length of all the IRs combined by running an irscan with a sentinel value (0x1) and varying the number of bits. When you see a 1 followed by 0s as you increase the bit-width of the IRs, you've found the combined size of the IRs. Of course, that doesn't tell you anything about how that size isdivided among the devices in the chain.On Fri, Feb 6, 2009 at 8:15 AM, Rick Altherr <kc8...@kc8apf.net> wrote:On Feb 6, 2009, at 1:08 AM, Martin Haeberli wrote:...v[4]=0x1eThis looks like an old-style jtag_device command. You'll want to convertit to the new-style jtag newtap command.Thanks for the suggestion - I'll give that a try today.It won't really change anything other than get you on to the newer syntax.The two syntaxes are equivalent....n big -chain-position 0And then the argument to -chain-position will change.To what? Candidly, I'd like to figure out a way to explore the available scan chain to see what is there.The argument to -chain-position references a jtag_device or jtag newtap command. If you are using jtag_device, the argument is which jtag_device command you are referencing. If you are using jtag newtap, the argument is the name of the tap you created. See the config files included with OpenOCDfor examples.Debug: 76 266 openocd.c:150 handle_init_command(): jtag interface init...Debug: 88 281 openocd.c:156 handle_init_command(): jtag init completeLooks like the JTAG hardware failed to communicate at all. Both theexamineand validate failed which means OpenOCD cannot talk to anything on theJTAG chain. I'm not sure why we bothered to continued after this point.Something is wrong with either the JTAG chain configuration or the JTAGhardware.----...jtag_device 5 0x1 0x1 0x1eChange this to a jtag newtap command.OKThanks, de W9MPH - Martin-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split itwith him." -- Unsigned
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
