Rick, I am running > version Open On-Chip Debugger 1.0 (2008-11-05-01:04) svn:1135
Perhaps I should somehow update to a more recent release? 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. 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 pow er 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. 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 USBJTAGNT >> hack 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 ROM >> on 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 I >> don'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 documentation > online. > > 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 is > divided 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]=0x1e >>> >>> This looks like an old-style jtag_device command. You'll want to convert >>> it >>> 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 0 >>> >>> And 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 OpenOCD > for examples. > >>>> Debug: 76 266 openocd.c:150 handle_init_command(): jtag interface init >> >> ... >>>> >>>> Debug: 88 281 openocd.c:156 handle_init_command(): jtag init complete >>> >>> Looks like the JTAG hardware failed to communicate at all. Both the >>> examine >>> and validate failed which means OpenOCD cannot talk to anything on the >>> JTAG >>> chain. I'm not sure why we bothered to continued after this point. >>> Something is wrong with either the JTAG chain configuration or the JTAG >>> hardware. >>> >>>> ---- >> >> ... >>>> >>>> jtag_device 5 0x1 0x1 0x1e >>> >>> Change this to a jtag newtap command. >>> >> >> OK >> >>>> >>> >> >> Thanks, >> 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 it > with him." > -- Unsigned > > > > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
