[This is the schematic to my LPC2148 board and I have it connected (there is a jumper, but I will check it if it is OK).
I also tried it with MCB2130 board from Keil and I got the same error. (I used the same project - LPC2148Test - on this board).
I should probably also say that this is the first time I tried to use a JTAG and that I don’t know if it works (I recently built it on a protoboard).](http://po.labs.googlepages.com/nart2148.jpg)
This is what I got when I measured all the signals with the oscilloscope:
TDI - starts with low and than it sends a signals openocd-pp is running
TMS - starts high and goes low while openocd-pp is running
TCLK - starts with low and than it sends a signals openocd-pp is running
TDO - always low
nSRST - always high
nTRST - always low
This was tested at jtag_speed=500.
Can you tell me what should each signal look like?
TDI, TMS and TCLK look like they work, but this is just output from the PC, but the output TDO from the LPC2148 doesn’t look like it reacts this signals.
djurodrljaca:
I measured nTRST again and found out that it sends a short pulse.
Here are the signals that I measured:
SNIP******
The signals nSRST (high) and TDO (low) didn’t change.
If your waveforms were taken at the chip pins then your nTRST signal is inverted from what it should be. The “n” in nTRST indicates that it is negative true logic, so your nTRST signal is actively holding the EmbeddedICE TAP controller in reset for all but the short pulse that your waveforms show. With the TAP controller in RESET there can be no signal out of TDO, so the JTAG link is completely dead. You need to invert the nTRST signal to produce a negative pulse instead of a positive pulse. Actually it would be better still to produce the negative pulse on nSRST and reset ARM, since nTRST only resets the TAP controller without reseting the ARM core.
I think that there could be some software/configuration error, since you should be able to set the polarity within reset_config (at least that is how I understood it). So than I tried to use “reset_config trst_and_srst separate trst_open_drain srst_open_drain” but it still works the same as “reset_config trst_and_srst srst_pulls_trst”.
I also tired to set “parport_cable chameleon” instead of “parport_cable wiggler” which was used as default and than the nSRST signal goes low and high repeatingly. So it look like all the parts on my wiggler work and this is why I think the problem is with software/configuration.
The schematic you used has a bug, sorry about that. I never actually built that device, I just tried to draw a schematic that implements both reset lines, as most existing schematics only had one. On a real wiggler, the nTRST line isn’t inverted, i.e. the host sets the line low when it wants to initiate a reset, and high to keep it deasserted.
If you can compile the OpenOCD yourself, try adding this line to the list of cables in parport.c:
The options that set the reset lines open-drain or push-pull only affect devices were this is configurable like the Amontec JTAG Accelerator or the various FT2232 based devices (JTAGkey, ARM-USB-OCD, OOCDLink etc.).
The “chameleon” cable layout is only used when programming the Amontec Chameleon itself, i.e. when a new configuration should be loaded to the CPLD.
