JTAG / SWD (Nucleo?) over SPI code example

[Aleksejs_S]

Hello,

I got a radio MCU which connects to cloud and can receive binaries from database. And I got a STM32 that controls some stuff, including other MCUs. In production this means a lot of headers and programming time for all of them, no way to update remotely, and even if the code is thoroughly tested - glitches are still possible.

So I want to connect things in a chain, so that if something apart from the radio crashes - radio MCU could re-flash the whole system. This of course could be done with UART when using bootloaders, but this again means you have to pre-program bootloaders on MCUs, and there's still a very slim chance it might fail.

So I need an example of how one MCU can flash another via JTAG or SWD (preferably), and then verify the result. From there I could get it to work on Arduino / STM / AVR / radio ARM. What I really want is a proof of concept simple test example to show it works with the peripheral (bit banging is always possible, but surely there is a smarter way to do it using existing MCU resources), before I go ahead and order prototype boards.

In general this should not be black magic, we've all got some Nucleo boards, which are a great example that programming STM32 with STM32 is possible. On my NucleoF722ZE, the STM32F103CBT6 does the programming. It should receive packets via USB, then program the main MCU via either JTAG or SWD. It has a pair of jumpers - CN4, when closed - the jumper connects T_JTCK with SWCLK, and T_JTMS with SWDIO, and programs the big MCU via SWD interface.

When I look at how these signals are wired, I see this:
PB14 (SPI2_MISO) - T_JTMS - SWDIO
PB13 (SPI2_SCK) - T_JTCK - SWCLK
PB12 (SPI2_NSS) via resistor - T_JTMS - SWDIO

It leads me to think that SWD is done somehow with SPI2 in half-duplex master mode. I've seen people mentioning SPI for JTAG more than once, but I haven't found a good example.

If STM has the code for Nucleo STM32F103CBT6 programmer freely available - that would be everything I need to proceed with my project. But I can't find it.

What I have found so far:

JTAG bit-banging example: https://github.com/openwch/usb-jtag-spi/tree/main/src/OpenOCD/USB20JTAG

Free DAP, also bit-banging: https://github.com/ataradov/free-dap/blob/master/dap.c

Arduino SWD programmer, bit-banging: https://github.com/dimitar-kunchev/arduino-swd-programmer-samd/tree/master

LibSWD, opensource project to make SWD more available: https://github.com/cederom/LibSWD/tree/master

There are Black Magic probe source codes: https://github.com/blackmagic-debug/blackmagic

Wiki page on ST-link with some links to firmware reverse-engineering: https://stm32world.com/wiki/ST-Link

There's a lot of references to OpenOCD, but it's a ton of information, and at this point I don't even see if it's useful for me:
https://openocd.org/doc/html/index.html

https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi/wiring-and-test

There is a topic on Hackaday, which is about the hardware and firmware of STlink: https://hackaday.io/project/179054-custom-st-link-v20-v21-v30/details

At this point I'm just shocked that programmer firmware is something that people need to hack, instead of ST just providing a source code so people can use it with their ICs.

SWD tutorial page: https://robo.fish/wiki/index.php?title=SWD

ST-link open source project: https://github.com/stlink-org/stlink

There is also an adaptation of libSWD for ESP32 which in fact uses SPI, and this might be the most relevant resource: https://github.com/PaulFreund/libSWD-esp32

So it's not like there is no information on the topic. Almost all the code I found seems to bit-bang the data. I find it hard to believe that both JTAG and SWD on all STM32-based programmers are wired to SPI peripheral by pure coincidence :D Especially after that last repo for ESP32, which reads it via SPI.

Or maybe I'm just blind and don't see something right in front of me, and someone will be able to point it out :D

It looks like the best approach is to adopt Paul Freund's project to some Arduino board and check out if it works fine. In the meantime, if anyone knows of original STM32 STlink source, or SWD example, or Arduino/STM32/AVR source that uses SPI to do SWD, to upload the flash to STM32 and check if it uploaded correctly - please drop a comment.

I hope if this does not get resolved, at least the stuff I collected here might be of use.

UPD. 1

Another project, using SWD over SPI with Raspberry PI: https://github.com/lupyuen/pi-swd-spi

And it has a cool spreadsheet with commands and bits: https://docs.google.com/spreadsheets/d/12oXe1MTTEZVIbdmFXsOgOXVFHCQnYVvIw6fRpIQZybg/edit#gid=0

UPD. 2

A very interesting blog post explaining how to do SWD over SPI: https://www.pcbway.com/blog/technology/OpenOCD_on_Raspberry_Pi__Better_with_SWD_on_SPI.html

An Arduino example for monitoring SWD line (might be useful to test or verify something): https://levelup.gitconnected.com/listen-up-how-to-monitor-uart-i2c-swd-and-spi-with-arduino-9d8ef25da308

[Tesla DeLorean]

JTAG / SWD control is non-trivial and documented by ARM. You'd need to push in code specific to the STM32 to write FLASH, via the normal registers and interaction. 

Less complex would be to initiate the ROM loader and use UART (AN3155) or other supported peripherals and protocols (AN2606) to communicate with code provided to do that.

[Aleksejs_S]

Hi. Yes I know it would be less complex, but you're missing the point. Every ST-LINK does it, and there's a bunch of projects where people have done it. So non-triviality doesn't matter - it's done. In most cases it's done with bit-banging which is usable and portable, but not the best way to do it IMHO. So I did a bit of research and found out it has also been implemented over SPI by few awesome people.

I can try to adapt the code from PaulFreund or lupyuen, and I will do so if I need to. But it will take days to rewrite and test, and I don't want to reinvent the wheel if it's already been done by smart people, or ST have since published their sources, and I just didn't think to look for sources in the most obvious place.

So perhaps my explanation of what I wanted to achieve was a bit blurry - I am looking for an easier to use example, not alternatives or reasons to not do it :D While looking for materials, I've seen some 15+ people trying to do the same thing to simplify their production, not to mention those who try to clone ST-link for whatever reasons, so I believe this is a useful exercise.

[Piranha]

Take a note that setting an RDP level 2 disables the SWD/JTAG debug interfaces completely and permanently.

[Aleksejs_S]

Thanks for your input, this is of course good to remember. Yet this is a slightly different topic. I've really started this hoping that someone might add more information to the links I collected - solutions that are easier to port or test out, vids with explanations, links to repos.

[Mike Ciholas]

I've thought about how an SPI port can do SWD and here is my concept that I have not seen implemented.  There is a small bit of electrical trickery to deal with the bidirectional nature of SWDIO.  Here is the connection:

SPI SCLK ties to SWCLK.  This is always unidirectional from host to target.

SPI MISO ties to SWDIO.  This allows the host to read the bits sent from the target to the host.

SPI MOSI ties to SWDIO through a resistor, say 1K.  This sends the bits from host to target.

The key insight here is that when the target is NOT driving SWDIO, the MOSI signal does through the 1 K resistor.  When the target does drive SWDIO, the pin driver is strong enough to overcome the 1 K resistor and the MISO line picks up that signal.

An SWD transaction is 46 bits.  For the bits sent by the host, set them to the desired bits you want the target to get.  For the bits in the turn around spots, send a '1' and that provides a pullup on the SWDIO line.  For the bits the target is supposed to drive, do the same, send a '1'.  The target will replace the '1' with the bits it is driving.

Since SWD transaction is 46 bits, send a 48 bit SPI block and put two '0' bits at the end (or the beginning, doesn't matter).  SWD transactions start with a '1' bit so the '0' bits will be ignored.

I think the proper CLK settings will be CPHA = 1, CPOL = 0 to get the right edges to clock on, but this is untested.

SWD requires a "reset" sequence of all '1's for 50 bits, so send 56 bits of '1' to achieve that.

I believe you can setup the 6 byte SPI outgoing bits, send them, and then decode the 48 bits you got back to align the response, check the ack bits, and do any bit swapping. (say lsb first versus msb).

The MOSI resistor does limit clock speeds somewhat.  Assuming a 20 pF wire loading, that is 20 ns delay on the MOSI to SWDIO signal with a 1 K resistor.  This suggests you should operate probably no faster than about 20 MHz, maybe 10 MHz, but this should still be a lot easier and likely faster than bit banging.

This idea is entirely untested, unimplemented, just a concept I had, so let me know if anybody gets it to work.

[Uwe Bonnes]

SWD is tree parts: - Write some kind of 7 bit address, read 3 bits answer from the device and exchange 33 bits of data with eventually a turnaround bit in between these chunks.  Older STM32 SpI can not do the 4 bit transfer needed to read the answer.  So either bitbanging is needed for that part. Pin usage on the STLinks lets me assume, two SPI units are used in the STLink.

[Mike Ciholas]

SPI is both write and read at the same time.  With the resistor trick, MOSI drives the SWDIO through the resistor when the target is acting as an input, and MISO reads the target driving the SWDIO during reads (as well as echoing the MOSI output during write).

The SWD transaction starts with a '1' bit.  If you clock in proceeding or trailing '0' bits, they cause no harm and are ignored.

This is a write:

Assuming an 8 bit SPI interface, you send two bytes for the header:

0, 0, 0, Start (1), APnDP, Write (0), A[2:3]

Parity, Stop (0), Park (1), Trn (1), Ack[0:2] (111), Trn (1)

You can now look at the ack bits and if you get the OK response (100), then you proceed with the data write in 5 bytes:

Wdata[0..7]

Wdata[8:15]

Wdata[16:23]

Wdata[24:31]

Parity, 0, 0, 0, 0, 0, 0, 0

If you get the WAIT or FAULT response, handle them as appropriate.

The leading zeros in the first byte and the trailing zeros in the last byte are ignored and are harmless.

This is a read:

The header is bit shifted one bit later due to not needing a Trn between ack and data:

0, 0, 0, 0, Start (1), APnDP, Write (0), A[2]

A[3], Parity, Stop (0), Park (1), Trn (1), Ack[0:2] (111)

You can now look at the ack bits and if you get the OK response (100), then you proceed with the data read in 5 bytes:

1, 1, 1, 1, 1, 1, 1, 1

1, 1, 1, 1, 1, 1, 1, 1

1, 1, 1, 1, 1, 1, 1, 1

1, 1, 1, 1, 1, 1, 1, 1

Parity, Trn (1), 0, 0, 0, 0, 0

The MISO line will clock in the target read back response while you are clocking out 1.

You don't need to do any bit banging, just clever alignment of SPI bits.  There are some wasted clock edges, you clocked 56 bits to handle a 46 bit transaction, but that's relatively minor overhead to get the benefits of using the SPI peripheral to clock things in without bit banging.

Mike C.

[Uwe Bonnes]

The resistor trick will not work when voltage translation is needed. Otherwise, if the device signals wait or error, the protocoll tells not to do the (R|W)DATA transaction and doing the transaction despite may upset the device. This may require  reinitialization. So only a four byte transaction to read "ACK" allows to stay in the protocoll.

[Mike Ciholas]

Voltage translation occurs at the MISO, MOSI levels, then do the resistor in the target voltage domain.  MISO, MOSI are unidirectional signals, so easily translated.  This can occur even after isolation, say after ISO6xxx isolators are used which provides both isolation and target voltage translation.

Once you do the first two bytes, which have the header and ack bits, you can check the ack codes and respond to them.  A WAIT or FAULT response means you don't do the data portion unless you have overrun detection enabled, then you do a data portion.  The alignment of the SPI bits is done precisely so that you can stop after the ack bits.

You could always enable overrun detection and then always have a data portion.

If you have a protocol error, the target provides no ack bits, then do the resync procedure (send 50 1 bits which can be 6 '0' followed by 50 '1' to make it work with 8 bit SPI) and then read the IDCODE register.  Now you are back in sync.

Mike C.