4
\$\begingroup\$

SOLVED - LOOK UNDER "EDIT 3" SUBTITLE.

I've got this two chips: Board with LPC4337(left) and board with ATSAM3X8E(right), JTAG interconnected, using FT2232H chip soldered on the board of the left as an interface.

Board with LPC4337(left) and board with ATSAM3X8E(right), JTAG interconnected, using FT2232H chip soldered on the board of the left as an interface.

The first one (LPC4337) can be programmed. The second one (ATSAM3X8E) can be programmed too as long as traces between the programming chip (FT2232H) and the LPC4337 MCU are cut. If no traces are cut (both LPC4337 and ATSAM3X8E connected to the JTAG) then I can't access the ATSAM3X8E chip. I'm using OpenOCD. This is OpenOCD output when both chips are connected to the JTAG:

...

Info: JTAG tap: lpc4337.m4 tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part:0xba00, ver: 0x4)

Info: JTAG tap: lpc4337.m0 tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd.), part:0xba01, ver: 0x0)

Info: JTAG tap: sam3.m3 tap/device found: 0xfffffff (mfg: 0x7ff (), part:0xffff, ver: 0xf)

Error: sam3.m3: IR capture error; saw 0x0f not 0x01

Warn : Bypassing JTAG setup events due to errors

Error: Invalid ACK (4) in DAP response

Error: Invalid ACK (4) in DAP response

Error: Invalid ACK (4) in ... (many more)

Error: Invalid ACK (0) in DAP response

Error: Could not initialize the debug port

Some notes: If I change OpenOCD config to ignore the "IR capture error", the connection fails anyways, the first problem is the sam3.m3 TAP ID being detected as 0xfffffff etc.

Same output with LPC4337 JTAG traces cut (only ATSAM3X8E connected):

...

Info: JTAG tap: sam3.m3 tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part:0xba00, ver: 0x4)

Info: sam3.m3: hardware has 6 breakpoints, 4 watchpoints

Some notes: This is a successful connection.

An interesting thing is that both LPC4337 and ATSAM3X8E share the same JTAG TAP ID. Isn't this value chosen by the manufacturer? Is having different chips with the same JTAG ID a strange coincidence? May this be the problem preventing me from connecting both of them to the JTAG? I've seen repeated JTAG IDs being handled by OpenOCD before, but always with different instances of the same chip, not from different chip families like in this case. Is there a way to change chips JTAG ID? What other problems could be causing this behaviour? I'm interested to hear any kind suggestions, even if they turn not to be the solution they might help.

Some other notes: I've tried with two different ATSAM3X8E boards so I know the chips aren't faulty. Both boards were Arduino Due and worked when LPC4337 JTAG traces were cut. I'm running OpenOCD version 0.10.0 ("Freddie Chopin" compiled version) on Windows. I haven't got an oscilloscope. I would like to work with both MCUs without adding more modifications or cutting traces. I would also like to understand the fault that's preventing me to program these chips in case I design something in the future using them.

Lastly, I would like to thank the community for their time, I hope this post helps some other people in the future!

EDIT:

These are the JTAG interface schematics of both boards that were connected together. The flat cable is connecting Pin1 of "P3" connector on LPC4337 board schematic with Pin1 of "JTAG" connector of ATSAM3X8E board schematic, etc. (All 10 pins connected accordingly, tested with continuity with a multi-meter). enter image description here This is LPC4337 board schematic.

This is ATSAM3X8E board schematic.

EDIT 2:

Thanks to the answers I found out I was using a star JTAG topology but a daisy chain JTAG topology would be the standard approach. I will change my wiring and post my results. Thanks for the help. This will be my wiring topology (but with two devices): New topology
EDIT 3:

JTAG was changed from a star topology to a daisy chain topology. LPC4337 TDO is routed to the connector and eventually to ATSAM3X8E TDI. ATSAM3X8E TDO connects via the connector to the FT2232H interface. When no device is connected and only the LPC4337 is being programmed, a little male connector (pictured below) can be plugged (instead of the cable) and bridges LPC4337 TDO directly to the FT2232H interface. New setup OpenOCD connection succeeds and outputs the following:

...

Info: JTAG tap: lpc4337.m4 tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part:0xba00, ver: 0x4)

Info: JTAG tap: lpc4337.m0 tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part:0xba00, ver: 0x4)

Info: JTAG tap: sam3.m3 tap/device found: 0x4ba01477 (mfg: 0x23b (ARM Ltd.), part:0xba00, ver: 0x4)

Info: lpc4337.m4: hardware has 6 breakpoints, 4 watchpoints

Info: lpc4337.m0: hardware has 6 breakpoints, 4 watchpoints

Info: sam3.m3: hardware has 6 breakpoints, 4 watchpoints

(the 0x4ba01477 TAP ID turned to be the ATSAM3X8E, I wonder if OpenOCD could be arranged in a different order [atsam, lpc m0, lpc m4] and work in a star topology or not)

Thank you all for your help!

\$\endgroup\$
6
  • 1
    \$\begingroup\$ I get the impression that both chips' JTAG porta are electrically in parallel so my question to you is; what makes you believe you can accomplish this at all? \$\endgroup\$
    – Andy aka
    Commented Jan 29, 2018 at 13:44
  • 1
    \$\begingroup\$ I understand that JTAG allows addressing multiple chips on a same board. Meant to provide only one connector to program MCUs, FPGAs, EEPROMs, etc. Is my understanding incorrect? I saw OpenOCD outputs on the web showing more than one FPGA in the same board being recognized, I figured MCUs should work the same way. Feel free to correct me or ask anything related to my circuits/configurations ! Thanks for your answer \$\endgroup\$
    – Juan Manuel López Manzano
    Commented Jan 29, 2018 at 13:52
  • \$\begingroup\$ Please post a schematic of your connection diagram. \$\endgroup\$
    – Lior Bilia
    Commented Jan 29, 2018 at 13:57
  • 2
    \$\begingroup\$ I'm not an expert but don't the ports need to be wired in a daisy chain using TDO and TDI? \$\endgroup\$
    – Andy aka
    Commented Jan 29, 2018 at 14:03
  • \$\begingroup\$ Andy aka, I guess they kind of are. Wouldn't connecting all JTAG connector pins together be what you mean? Would you wire them differently? When LPC4337 JTAG traces are cut ATSAM3X8E JTAG interface starts working so I guess the wiring is correct. But maybe it isn't. Please feel free to suggest a different wiring strategy. I have cut and rewired LPC4337 JTAG traces more than once, and every time the traces are cut ATSAM3X8E interface works, and stops working when traces are rejoined. Please, if you know something about my TAP ID questions let me know. Thanks in advance! \$\endgroup\$
    – Juan Manuel López Manzano
    Commented Jan 29, 2018 at 14:36

1 Answer 1

Reset to default
2
\$\begingroup\$

The comments suggest you are trying to operate in 'star topology', but as far as I know, that isn't a well defined implementation.

Please confirm you're using daisy chained topology, where the multiple TAPs make up a single long shift register. Debug tools ought to cope with this since it sometimes occurs implemented in a single chip.

The TAP IDs that you quote are for the debug interface, they don't (and don't need to) identify the individual hardware. All they define is that these components use Arm CoreSight JTAG-DP, which provides an interface to memory mapped debug components. If you access the debug components in that memory map (which are discoverable from the registers that the DP provides), then you should find an ID value which ultimately identifies the chip.

The JTAG-DP IDCODE register is described here in ARM DDI 0314H.

\$\endgroup\$
6
  • \$\begingroup\$ Yes, the FT2232H chip connects to the two chips JTAG interface using the same pins. What do you mean by "...but as far as I know, that isn't a well defined implementation...." ?? Do you mean that chips JTAG interface may be conflicting with one another because of manufacturers not designing their products to support daisy chaining?. I don't understand what you mean by "where the multiple TAPs make up a single long shift register." I guess you mean that by shifting one FT2232 bit both boards "receive" the signal? \$\endgroup\$
    – Juan Manuel López Manzano
    Commented Jan 29, 2018 at 14:44
  • 1
    \$\begingroup\$ Daisy chain is well supported. Star topology requires that the TDO pins are tri-stated when a TAP is inactive (and I can't think off hand how the selection would work). You're trying to use STAR. It won't work. \$\endgroup\$
    – Sean Houlihane
    Commented Jan 29, 2018 at 14:48
  • \$\begingroup\$ Thank you for the TAP ID clarification. I guess there shouldn't be any problems with a repeating TAP ID as long as OpenOCD is configured to "tap" all chips in the order they end up presenting. (I also tried "taping" the ATSAM3X8E before the LPC4337 but didn't work and in my particular implementation LPC4337 M4 ARM core seems to always be the first core detected, followed by the LPC4337 M0 and lastly the ATSAM3X8E M3) \$\endgroup\$
    – Juan Manuel López Manzano
    Commented Jan 29, 2018 at 14:50
  • \$\begingroup\$ "Star topology requires that the TDO pins are tri-stated when a TAP is inactive". So should I be turning TDO signal of a particular chip interface to high impedance while trying to connect to the other? The FT2232H chips output is connected to a buffer that allows tri-stating all signals (but for both chips) would the signals need to be individually tri-statable for each chip? \$\endgroup\$
    – Juan Manuel López Manzano
    Commented Jan 29, 2018 at 14:53
  • 1
    \$\begingroup\$ No, just use daisy chain. \$\endgroup\$
    – Sean Houlihane
    Commented Jan 29, 2018 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.