FT232H and almost universal USB <-> JTAG adapter for 15 euros

Continuing the topic of practical application of the FTDI FT232H chip, which I touched on in the previous article , I would like to talk about using a debugging board on it as a cheap and almost universal JTAG adapter with USB interface and support for many microcontrollers of various architectures and manufacturers. I deliberately do not call this adapter "JTAG debugger", because not all devices with JTAG TAP support debugging, but ordinary users use the JTAG adapter in most cases for flashing and debugging their code on the MC. In this article, I will describe only my own experience of using the FT232H as a JTAG adapter in order not to give references to unverified solutions, so I invite readers to share their (or others) ways of using this chip in the comments. I am sure that there will be much more of these methods than described here.
Interested please under the cat.

A couple of words about FT232H

If you are not familiar with the FTDI FT232H chip, read the article about it and come back. If you read other articles are not in your plans, then let me repeat myself a little:
The FT232H and its older, but different brothers: the two-channel FT2232D, its USB 2.0 version FT2232H, and the four-channel FT4232H are USB <-> USART controllers with an additional mode of operation that provides hardware support for the SPI protocols (the SPI programmer assembly was described in the previous article), JTAG (work with which will be described in this) and I2C (which I will not consider yet).
The chip itself is quite cheap, and in small batches it costs about 200 rubles , but it is produced in LQFP and QFN cases that are not very convenient for DIY, so the easiest thing to buy is not the chip itself, but a ready-made breakout board like this (those 15 euros for dual-channel FT2232H from the article title), or such (600 rubles without delivery), or such (also 600 rubles, but in another place), or any other chip is popular, therefore there are a lot of different boards on it. Try to choose one on which the EEPROM chip is already soldered for storing settings - it will be much easier to pretend to be other devices, which may be needed more than once in the future.

A couple of words about JTAG

If you are not familiar with the JTAG interface, read this article here and come back. Generally speaking, the JTAG Test Access Port is, first of all, an interface for debugging the hardware of the device, not for its program, but, “not to run twice,” the vast majority of programmable microchips with this interface support the firmware and debugging of the code through it. . On the other hand, often even 4 free outputs (and JTAG requires at least 4) are not available on the MK, and most manufacturers suffer (and often even enjoy) NIH syndrome, therefore instead of JTAG there are various proprietary interfaces, such as SWD from ARM (the protocol is the same, only 2 pins instead of 4), BDM from Freescale and Motorola (another protocol, one bidirectional output is enough), Spy-Bi-Wire from Texas Instruments (another JTAG version with 2 pins), DebugWIRE from AVR ( simplified debugging protocol, which is enough output 1) and others. Some of them, if desired, can be implemented on the FT232H base using software, using the chip as a USB <-> GPIO adapter, and SWD and SWV using competent switching, as done in the KT-Link debugger and its emulator based on an open debugger BusBlaster . On the “bare” FT232H of the aforementioned debugging interface options, only JTAG is supported, keep this in mind.
')

We flash and debug ARMs

Due to the fact that many common debuggers are based on FT232H, the easiest way to add support for our board to IDE and other utilities is to emulate these debuggers. Some features may not work, but this trick eliminates writing your drivers. The easiest way is to pretend to be an open CoLink debugger (without the Ex suffix), the scheme of which differs from most breakout boards only by the presence of a buffer. Moreover, CooCox IDE directly supports the use of any devices based on FT232H as a debugger after the preliminary configuration , and for Keil uVision and IAR Workbench there are plug-ins, and neither Vendor ID nor Product ID will need to be changed, since CoLink uses both standard FT232H VID and PID, as well as standard FTDI D2XX drivers.
If your OS is different from Windows and you are not interested in either Keil, IAR, or CooCox IDE - pay attention to the UrJTAG and OpenOCD projects that have full support for FT232H-based debuggers. I work at Keil uVision4, and this choice was not made by me, so I can’t talk more about using FT232H in Linux and OS X yet.
In Keil, it is enough to install the plugin , select the correct Target and CoLink as a debugger in the project properties, after which both firmware and debugging will run from the IDE without using any third-party software.
Unfortunately, I can not find a complete list of compatible with CoLink chips (the official is on the link above, but it is far from complete), so you will have to either try or use the list of compatibility with OpenOCD. In general, it is best to just try, there is a high probability that it will work immediately.

Flash and debug XE166

I am sure that even many “experienced wolves” hear for the first time about this 16-bit RISC architecture, which is not very popular outside of its homeland - Germany. This architecture is already quite old, its initial modification was developed in 1993 by the Siemens concern in cooperation with ST for use in industrial automation, and it was then called C166. Later, in 2007, Infineon, already retired from Siemens, slightly modified this architecture, increasing the number of stages of the pipeline from 4 to 5 and adding a 32-bit addition-multiplication unit. The chips on the resulting XE166 architecture are still being produced , are widely used in German automation and are not going to become obsolete. Students of technical universities of the corresponding IT specialties teach them, so I had to deal with this architecture and chips on it.
My opinion is that normal chips for their tasks, a lot of peripherals (6 CAN channels with MultiCAN support, for example), up to 100 MHz with a capacity of 1 MIPS per MHz, but not without flaws - can easily eat 120 mA per 100 MHz without special computational load and almost completely disconnected from the clocking of the periphery, and even more complicated in programming, AVR, but at the level with typical ARMs of the same segment. Well, vendor lock-in, where without it.
Due to the rarity and low prevalence in the unincorporated market, debuggers for this architecture are either impossible to buy at all, or you can purchase hundreds of normal debuggers for other more popular architectures for their cost. But a close study of the devkit scheme , on which the very same FT2232D is found, suggests that the debugger can be obtained with little blood. That's right, but in Infineon, unlike CooCox, they decided to change the VID, PID and the serial number of the FT2232D installed on the device, so we will have to do this. We connect the devkit, wait for the installation of the drivers, run FT_Prog, write the VID, PID and serial number (I will add them to the article when I get to the devkit, now, I repent, I don’t remember), and then flash the same values ​​(the serial number can be slightly changed ) in our board's EEPROM (this is where it was needed). We disconnect the board from the PC, we reconnect - the new VID and PID are picked up by the drivers and then working with our board is not much different from working with the devkit - all the same Keil and Infineon DAS as a debugger.

Other uses

A search on thematic sites makes it easy to find a lot of other ways to use the FT232H and its brothers for firmware and debugging of MK and FPGA, but I haven’t come across them yet, so I don’t have the right to write about “practical use”. What does not prevent me, however, from asking readers who are familiar with these same methods to share them in the comments. Thanks a lot in advance.

Thank you for your attention and successful debugging.