#40 FT2232-based cable doesn't detect LPC2888

[Kolja Waschk]

A wiggler detects a LPC2888:

jtag> detect
IR length: 4
Chain length: 1
Device Id: 01001111000111110000111100001111 (0x000000004F1F0F0F)
Manufacturer: ARM

But a FT2232-based cable (I tried two different) fails to detect anything. Interestingly enough, on another board, it DOES detect the (different) ARM-based Samsung SoC there:

jtag> detect
IR length: 4
Chain length: 1
Device Id: 00011111000011110000111100001111 (0x000000001F0F0F0F)
Manufacturer: ARM

[Arnim Läuger]

Logged In: YES
user_id=156321
Originator: NO

Are the TRST or TSRST lines used on the failing system? The ft2232 driver doesn't care about other signals than TCK, TDI, TDO, TMS.

[Kolja Waschk]

Logged In: YES
user_id=478715
Originator: YES

You're probably right, there's an internal pulldown on nTRST... pulling nTRST high helps a little (now TDO is somewhat related to TDI), but "detect" still doesn't find anything. Probably the device needs a TRST in between; i.e. proper TRST support in the cable driver and not just a static pullup.

[Arnim Läuger]

Logged In: YES
user_id=156321
Originator: NO

TRST should be optional from the JTAG specification. I.e. a static 1 must be enough when the tap reset is performed by clocking TMS in the right way.
Have you tried to remove power from both the system and the ft2232 pod at the same time? I found that the chip and/or my board remain in strange states when things went wrong previously. Typically, detect doesn't find anything.

[Kolja Waschk]

Logged In: YES
user_id=478715
Originator: YES

Yes, it's obviously not just the nTRST pulldown. A comparison of the responses during detect_register_size (beginning with IR examination) shows different results when using wiggler ("wg") vs jtagkey (ft).

Registers rz.rpat=>rout printed using "register_get_string" in detect_register_size() at the beginning of the "detect" procedure:

ft rz=0.000000001 => 000100000$
wg rz=0.000000001 => 000010000$
ft rz=00.0000000001 => 0000100000$
wg rz=00.0000000001 => 0000010000$
ft rz=000.00000000001 => 00000100000$
wg rz=000.00000000001 => 00000010000$
ft rz=0000.000000000001 => 000000100000$
wg rz=0000.000000000001 => 000000010000$
ft rz=00000.0000000000001 => 0000000100000$
wg rz=0000.000000000010 => 000000100000$
ft rz=00000.0000000000010 => 0000001000000$
wg rz=0000.000000000011 => 000000110000$
ft rz=00000.0000000000011 => 0000001100000$
wg rz=0000.000000000100 => 000001000000$
ft rz=00000.0000000000100 => 0000010000000$
wg rz=0000.000000000101 => 000001010000$
ft rz=00000.0000000000101 => 0000010100000$
wg rz=0000.000000000110 => 000001100000$
ft rz=00000.0000000000110 => 0000011000000$
wg rz=0000.000000000111 => 000001110000$
ft rz=00000.0000000000111 => 0000011100000$
wg rz=0000.000000001000 => 000010000000$
ft rz=00000.0000000001000 => 0000000000000$
wg rz=0000.000000001001 => 000010010000$
ft rz=000000.00000000000001 => 00000000100000$
wg rz=0000.000000001010 => 000010100000$
ft rz=0000000.000000000000001 => 000000000100000$
wg rz=0000.000000001011 => 000010110000$
ft rz=00000000.0000000000000001 => 0000000000100000$
wg rz=0000.000000001100 => 000011000000$
ft rz=000000000.00000000000000001 => 00000000000100000$
wg rz=0000.000000001101 => 000011010000$
ft rz=0000000000.000000000000000001 => 000000000000100000$
wg rz=0000.000000001110 => 000011100000$
ft rz=00000000000.0000000000000000001 => 0000000000000100000$
wg rz=0000.000000001111 => 000011110000$
ft rz=000000000000.00000000000000000001 => 00000000000000100000$
wg rz=0000.000000010000 => 000100000000$

That was a clean start of UrJTAG (just "detect" after "cable") immediately after giving power to target and USB cable.

[Arnim Läuger]

Logged In: YES
user_id=156321
Originator: NO

My initial though was: there's an extra clock for the ft2232 pod. Some ideas to check:
* reduce the cable frequency (#define FT2232_MAX_TCK_FREQ 6000000 in ft2232.c)
* does the pod drive TCK, TMS and TDI with a push-pull driver?
level shifter outputs activated?
* weak pull-ups or pull-downs that fight against the level shifter outputs?
* coupling between signal lines?
* inverter on TCK?
Pretty unspecific, but I can't think of a conceptual problem with the cable driver - who knows.

[Kolja Waschk]

Logged In: YES
user_id=478715
Originator: YES

It _does_ work if I use a "generic_flush*" and the "generic_transfer" transfer (which is using only clock and get_tdo and nothing cable-specific).

It does _not_ work with generic_flush* but native ft2232_transfer, nor with all native ft2232*.

The target has a pulldown on TCK and pullups on the other lines. It doesn't make a difference whether the target is directly connected to the FT2232 pins or through level shifters (JTAGkey). Lowering frequency doesn't change anything. I tried to add pulldown/up on another board which _does_ work and it still _does_ work.

I'll examine the situation to with a scope tomorrow.

[Kolja Waschk]

Logged In: YES
user_id=478715
Originator: YES

all clear - lowering the freq did it. my first attempt (reported below) failed because I didn't patch at the right place, and frequency command doesn't work for usb cables (see other bug)

[Arnim Läuger]

Logged In: YES
user_id=156321
Originator: NO

Interesting to read that the frequency command didn't help but changing the #define did. There's code in the ft2232 cable driver that checks for updates of the cable frequency setting and is supposed to adjust the ft2232 frequency accordingly.
So is can it be confirmed that the ft2232 driver doesn't set the maximum TCK frequency correctly after the (long & tedious) frequency command? If yes, it's worth a bug report for this.

[Kolja Waschk]

Logged In: YES
user_id=478715
Originator: YES

No, changing the #def didn't work, that's why I first reported that lowering the freq doesn't help (I actually didn't lower it, because I only changed the #def, and it didn't affect anything).

During initialization, the frequency is always set to maximum (divisor=0).

I directly modified the divisor in armusbocd_init. I actually don't know if the frequency changes after the "frequency" command is used; it always took too long so I just hit Ctrl-C and tried something else. See Bug:

1836319 Delay loop calibr. not needed for cables with their own TCK

I was about to move the cable_set_frequency to the cable drivers, but then I thought that your approach (the cable driver itself detecting if "frequency" was changed) is quite good to keep the list of exported functions per driver at a minimum. But then it should be implemented in the parallel-port based drivers equally; cable_delay could check if the frequency was updated and then do the calibration. Well, that could cause confusion if you just want to clock() but initially it takes ages for calibration.... ?

Maybe in future we invent some extra mechanism for _configuration_ of [cable|bus|flash] drivers.

Kolja