I trying to use the YAGARTO build to run OpenOCD. I followed the instructions and still get the dreaded Error Validating JTAG Scan Chain message.
I am using OpenOCD-pp with the giveio driver, and an Olimex Wiggler clone. I am using the LPC2xxx_pp.cfg configuration file, and it just does not work.
I have been through the doumentation multiple times. Spent hour with Google trying to find an answer. I appear to be the only person having problems with OpenOCD + Wiggler. All the other similar problems are with USB devices.
Try changing the BIOS settings for your parallel port. You could try Macraigors OCDRemote or OCDCommander (free as in beer), and see if these work. Maybe your parallel port needs some special settings before it works in dumb SPP mode.
When I connect to my Olimex LPC2124 board OpenOCD works in SPP, EPP and ECP modes. When I connect to my LPC2138 board it does not work in any parallel port mode.
I verifed that the connections, pull-ups and pull-downs are the same between my board and the schematic for the Olimex LPC2124 and LPC2138 boards.
When I connect to my LPC2138 board with power on, the scan chain value returned is 3F. With the debugger disconnected or board powered off, the value returned is 00. When I connect to the LPC2124 board and remove the DBG jumper, I also get the same failure and return value of 3F. I verified that the pull-down on my LPC2138 board is connected.
OCDRemote does work. After I run OCDRemote, OpenOCD runs and I can telnet to it and issue commands. However there is a perpetual message printing when in debug mode 3. The message is
do you have a reset supervisor chip on your board? Try setting the n[st]rst_delay values to a value high enough for your reset circuitry, 500 (measured in ms) should be enough.
There is no reset supervisor on the board. Only a reset button and a pull-up.
When I set the n[st]rst_delay values, nothing changed. In fact when I set these values to 10000, (for 10 Seconds) the failure occured immediatly, not after a 10 second wait.
I have to admit that I’m a bit confused about might be going wrong:
It works with another board, so it’s no problem with your OS, GiveIO, or your parallel port
It works with the 2138 board after using OCDRemote (the debug message is fine), so it’s nothing too wrong with the 2138 board either.
Is the LPC2138 a board you’ve designed yourself? Maybe there’s a problem with signal integrity - you could try lowering the TCK rate (increase the jtag_speed value, try 1, maybe 2).
When the board is powered, OpenOCD fails with the JTAG error. If I press the reset button, then OpenOCD works. This is probably a viable workaround, but a little annoying.
I tried all combinations of trst and srst in the reset_config line of the config file. All behaved exactly the same.
OCDRemote connects immediatly at power on or manual reset.
you mean you have to press the reset button once, and after that the OpenOCD works? I have no explanation for such a behaviour.
Do you have a multimeter or something else to measure the levels of the reset lines? What’s your setting for daemon_startup and the reset value for the target (reset_run, run_and_halt, …)?
Looked at TRST and SRST on a scope. TRST & SRST are both 3V when inactive. I see TRST and SRST go low at the same time. TRST stays low for 5ms and SRST is low for 56ms. They both return to 3V.
Here is the entire config file: (BTW, I have tried all combinations of reset_config.)
#daemon configuration
telnet_port 4444
gdb_port 3333
#interface
interface parport
parport_port 0x378
parport_cable wiggler
jtag_speed 0
#use combined on interfaces or targets that can’t set TRST/SRST separately
#reset_config trst_and_srst srst_pulls_trst
reset_config trst_and_srst trst_pulls_srst
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
#jtag nsrst_delay 500
#jtag ntrst_delay 500
#target configuration
daemon_startup reset
#target
#target arm7tdmi
target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4
The order of the parameters is fine, the comment is wrong. I’ll check the examples from the doc/ directory.
SRST staying low for longer than TRST might be a problem. I’ll check the code and test on board here to see if there’s something. Could you verify if these times are the same when it works and when it doesn’t?