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]=0x1eThis looks like an old-style jtag_device command. You'll want to convert itto 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 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 completeLooks like the JTAG hardware failed to communicate at all. Both the examine and validate failed which means OpenOCD cannot talk to anything on the JTAGchain. 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 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
