SparkFun Forums

[djurodrljaca]

I measured nTRST again and found out that it sends a short pulse.

Here are the signals that I measured:

1) TDI


2) TMS


3) TCLK


4) nTRST


The signals nSRST (high) and TDO (low) didn't change.

[dshuman]

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.

--Dave

[djurodrljaca]

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.

[Dominic]

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:
{ "wiggler_ntrst_inverted", 0x80, 0x10, 0x02, 0x04, 0x08, 0x01, 0x11, 0x80, 0x80 },

This tells the OpenOCD that nTRST is inverted, too, and should fix the problems you're seeing.

Regards,

Dominic

[Dominic]

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.

Regards,

Dominic

[djurodrljaca]

Is the nTRST the only problem?

If it is, than I think it would be easier for me to fix the hardware because I don't have the right SW tools to build the OpenOCD and it is probabl easier to fix for me.

You should probably add this "wiggler_ntrst_inverted" to the next version of OpenOCD or change the schematics for that wiggler.

So, what is the correct reset_config:
"reset_config trst_and_srst srst_pulls_trst"
or
"reset_config trst_and_srst"

with my wiggler (when I fix the nTRST)?

[Dominic]

Looking at the scope pictures you took nTRST seems to be the only problem, so changing this signal to non-inverted should work.

The correct reset_config for for a LPC2xxx is "reset_config trst_and_srst srst_pulls_trst", as the LPC internally asserts nTRST whenever nSRST is asserted.

Regards,

Dominic

[djurodrljaca]

Finally, it works.

Thanx guys.

[Berlech]

Ok, I understand that I will fix my hardware that nTRST will act noninverting. The remaining question is, What's about the nSRST line? Should this also act non-inverting or inverting like in the schematics of the openOCD documentation?

Thanks in advance,

Bernhard

[Dominic]

nSRST should be inverting like it is in the schematic, only nTRST was faulty.

Regards,

Dominic