devanlai
commented
7 years ago It's theoretically possible, though I'm not sure that the JTAG throughput will be satisfactory - the CMSIS-DAP commands for JTAG are very close to just passing bit-banging commands over USB HID, so the best-case performance would look similar to using a different adapter with a JTAG clock rate of 256KHz.
If you want to try it out yourself, here are the steps to do it: On the hardware side, there are two unused pins (PF0 and PF1) which you can use for JTDI and nJTRST. For RTCK, if you wanted to do adaptive clocking, it would be necessary to multiplex or repurpose one of the existing pins. Some possible candidates:
- PA13/PA14 - if you're not interested in debugging the debugger, you could use the debugger's SWDIO or SWCLK pin for RTCK.
- PB8 - if you set the option byte to disable the BOOT0 function, then you can use PB8 for anything.
- PA0/PA1/PA4 - you could drop one of the LEDs
In software, the source still includes a copy of the reference CMSIS-DAP JTAG bit-banging code, so enabling it is really just a matter of changing some defines and hooking up the relevant JTAG pin definitions.
xcvista
ildar
There are some scenarios where it is necessary to us the full JTAG interface instead of the SWD interface to connect the DAP to the DUT, for example a JTAG daisy chain, a Cortex-A target like the Raspberry Pi, or when the older ARM7/ARM9/ARM11 chips gets involved. Is it possible to implement full JTAG on top of the current hardware and software?
JTAG uses a few existing SWD pins along with a few more:
The RTCK pin worths some special mentioning: it is used on ARM7/ARM9/ARM11/Cortex-A chips to implement adaptive JTAG clocking. However this feature is entirely optional. You can just pull this pin down with a resistor and ignore it otherwise, if you have no plan on implementing JTAG adaptive clocking. There do exist some chips (like NXP LPC2103) that uses the pull down on RTCK to detect the presence of a debugger though.