I am thinking about a hobby project that have a microcontroller and a CPLD connected together. Is this the correct way doing it?


simulate this circuit – Schematic created using CircuitLab

Secondary questions:

  • Is there any "standard" pinout I should follow when designing the JTAG connector?

    Altera CPLD and ARM microcontrollers have very different semi-standard JTAG pinouts. Can I settle on something that is somewhat a standard that can be convenient in both environments? I am thinking about the CMSIS-DAP pinout (a standard used in ARM world) with the nTRST line routed to pin 7 (otherwise unused on CMSIS-DAP,) but subconscious told me that the Altera FPGA pinout may be better as USB Blaster can also be used in OpenOCD.

  • How to debug both chips at once, if it is even possible?

    Since I got both chips in the same JTAG chain, in theory I should be able to debug both chips at once. How to do so in practise? I know that OpenOCD+GDB can work for the ARM, but what about the CPLD?

    Also, in this arrangement, should I avoid SWD on ARM at all?

  • Is it a good idea to share clocks between the two chips?

    As suggested in the diagram, is it a good idea to clock the CPLD using the clock output feature of the MCU? How to keep EMC managed in this scenario?

  • What is a good bus interconnect for the two chips?

    Since the chip in question is fairly large a package, I can hook the CPLD off the exposed SRAM interface. Is it a good idea? Should I also hook up the I2C and SPI buses? And a few extra pins too?

  • \$\begingroup\$ An easy way to test whether a JTAG programmer will support both chips (or at least bypass the other chip) is to purchase an "altera epm570 development board" and an "stm32f103 development board". Both of these appear to have minimal, low-cost development boards available. If preliminary test shows unsatisfactory support for CPLD on the ARM JTAG tool, or unsatisfactory ARM support on the CPLD JTAG tool, then keep the JTAG interfaces separate. \$\endgroup\$ – MarkU Dec 26 '16 at 7:20
  • \$\begingroup\$ @MarkU I have both. How to test it? Connect my J-Link to the EPM570 dev board and connect my USB Blaster to the STM32F103 board, and check if they can still properly detect the chain? \$\endgroup\$ – Maxthon Chan Dec 26 '16 at 7:21
  • \$\begingroup\$ That's correct. The idea is to verify that the JTAG programmer can be configured to bypass the unused device. You may have to somehow tell the JTAG programmer what's in the JTAG chain, in case it cannot automatically detect the devices. \$\endgroup\$ – MarkU Dec 26 '16 at 7:33
  • \$\begingroup\$ @MarkU If both debug probes can properly detect the devices, how to proceed from there? Also do you have any answers regarding the additional questions? \$\endgroup\$ – Maxthon Chan Dec 26 '16 at 7:36
  • 1
    \$\begingroup\$ You have not shown pull-ups / pull-downs, which are normally required on TMS, TCK, TDI (normally pull-up) and TRST (pull-down). There is usually a small series resistor (33 ohm typical) on the TDO output. There is a nasty gotcha for parts without TRST and for those situations (common for FPGAs) TCK should be pulled down \$\endgroup\$ – Peter Smith Dec 30 '16 at 13:53

You've got a few questions there, I'll try to address them in order. First, for JTAG:

Conceptually, yes, that's correct -- JTAG is a chain / a shift-register and you've connected it as such. At a system-level, here are the thoughts I have:

  • Will I ever end up with a "broken" chain? I.E., are both devices in the same power-domain (on at the same time), and are both devices capable of JTAG operation regardless of state -- i.e., if software is not loaded, or is otherwise corrupt, is the JTAG TAP of the part unaffected?

  • Physically, how close are these devices located to each other? The simplest thing to do for TCK is to feed it to a clock buffer, and drive it point-to-point to each device. Otherwise, you can do simple transmission line design and route in a "fly-by" style, and terminate the line with AC termination (resistor and capacitor in series to GND). Even at slow JTAG speeds, a modern JTAG debugger may drive fast edges and the trace may end up long enough to warrant considering TL effects.

  • Is my JTAG software (urjtag, etc.) capable of handling a chain of dissimilar devices? Many JTAG solutions are very brittle, and break when unknown devices are in the chain. At a minimum, you should have the BSDL files of each device available so software recognizes them (via IDCODE), and knows how long the IR of each part is, at minimum. The JTAG DRs will then be defined on a per-part basis.

The most common issue I see folks run into are "broken" chains, where TDO doesn't make it out because one of the parts isn't there (removable add-in cards), is off, or otherwise in a state where JTAG is in-operable. Adding a bypass resistor that can be loaded to short TDI/TDO across a part may be a good idea.

Other issues include poor signal integrity on TCK -- I was on a project where the designer had TCK fanning out to I think 10+ nodes across many circuit boards, with no re-driving whatsoever. As you may imagine, the chain was basically unusable due to all the reflections and horrid signal integrity.

Secondary questions:

Is there any "standard" pinout I should follow when designing the JTAG connector?

No, but as you stated, there are pseudo-standards from the vendors, like Altera's for their USBBlaster/ByteBlaster/etc, or the "standard" ARM pinout for a J-Link or similar. What you need to consider is:

  • do you want to solder together custom harnesses for the debuggers? If so, how many do you have to build for your program / project? Hand-building 20 harnesses would suck, and a SW engineer is going to be really upset with you if he wastes 10 hours chasing a problem that turns out to be an intermittent crimp on TDO.

  • do you want to put an additional connector on the board just for JTAG, or utilize a connector-less solution like Tag-Connect that is more suited for end-of-line testing with a $0 BOM Cost?

In either case, you have to provide at minimum: VCC (for sense), GND, TCK, TMS, TDI, TDO and TRST# for a minimal JTAG implementation. ESD protection isn't a bad idea here either.

How to debug both chips at once, if it is even possible?

This is all on the host SW end -- you can do this, as long as your SW (urjtag, OpenOCD) can juggle the state of both parts, but it's tricky. I don't know what your application is, but my gut says you're going to spend most of your JTAG time for the CPLD programming it and maybe hooking into a ChipScope / SignalTap ILA instance. For the MCU, I can see more detailed debug going on for SW with a Segger J-Link or similar -- in this case, the debug software just needs to be intelligent enough to support a JTAG chain where it will over/undershift appropriately to handle the extra device in the chain. Ideally, the CPLD sits in BYPASS and simply adds an extra padding bit/clock cycle to the JTAG master.

Is it a good idea to share clocks between the two chips?

Sure, it saves you another oscillator, assuming electrically it works (VIH/VIL/etc.) and precision requirements are met. Are you OK with the CPLD being "dead" if the MCU doesn't come up first? It enforces a dependence in the system in terms of power-up order. I might add a RESET line driven by the MCU to the CPLD as well, so your MCU can hold CPLD logic in RESET, start the clock, and then de-assert RESET. I don't recall if that family of Altera part has an internal RC oscillator used for initial configuration.

As for EMI/EMC, that's out of scope here for this question (IMO), but follow best practices for a single-ended clock signal. Don't make it any longer than you need too, use series termination if needed, and use spread-spectrum if needed / tolerable.

What is a good bus interconnect for the two chips?

I don't know what your application is. SPI is simple and requires very few wires. Parallel would certainly work, but again, I don't know the data-rate or latency requirements, but of course it is more traces.

  • \$\begingroup\$ STM32F103 have its TAP enabled in 5-wire JTAG + SWD mode by default and the interface can be switched off in software. And yes I am okay with putting a connector for JTAG and create custom harnesses (I have already created harnesses for J-Link 20-pin to CMSIS-DAP 10-pin and USB Blaster 10-pin to CMSIS-DAP 10-pin in the form of criss-crossed crimped IDC) Both chip runs off the same 3.3V regulator. I can add pins to make the MCU reset the CPLD logic, and there is also another global reset signal that is emitted from the debug probe and can reset both chips at once. \$\endgroup\$ – Maxthon Chan Dec 30 '16 at 7:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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