Serial Wire Debugging the STM32 via the Bus Pirate

2 October 2010

So 10 days ago I saw a post on Dangerous Prototypes mentioning the new STM32 Discovery board. Needless to say, I had impulse-bought a couple from Digi-Key within minutes. Unfortunately, I didn’t bother doing much research at that point, so I was unaware that the ST-Link has no Linux support until they arrived and I went to go program one. I could have just rebooted into Windows, but that seemed like admitting defeat, and I don’t really like IDEs anyway. Serendipitously, I had been reading about the Serial Wire Debug protocol for the past couple of days, and it seemed like a pretty nice little protocol, so I wondered if perhaps I could get that working.

Step 1 - The Bus Pirate

Given that I own a Bus Pirate, it seemed like the natural tool for implementing a new protocol that I had just read about. I had never used it before or even indeed verified that it worked, but I’ll spare you a long recounting of how I spent several days fighting with it, and just note that a tedious firmware upgrade process is ESSENTIAL if you bought a Bus Pirate from Sparkfun. Once that was fixed, it was a breeze setting up some basic serial communications with the Bus Pirate using the binary raw-wire mode from a Python script, although as mentioned in a previous post, the timings are slightly off compared to what one might naively expect.

Step 2 - Debug Port Communications

So given the ability to send and receive bits and bytes via the Bus Pirate, Debug Port communications were relatively straightforward. It’s important to pay attention to the fact that register numbers and data are all sent LSB-first down the wire, but otherwise it’s a nice, simple protocol.

Step 3 - Access Port Communications

So next I turned to the Cortex-M3 AHB Access Port, which would allow me to start manipulating the chip proper. I’ll again spare you several days of agonizing debugging, and just point out that when you clear the xPWRUPREQ bits, the associated features will power down. In hindsight, that makes a lot of sense. The general operation of the AHB-AP is pretty simple. Set the Control/Status Word to auto-increment if you want that feature, write the desired address into the Transfer Address Register, and manipulate the contents of the Data Read/Write register to your heart’s desire. At this point I was able to scan over the chip’s memory and make a dump of its contents, so I went ahead and made a copy of the current program in flash, just to be safe. This turned out to be very useful indeed.

Step 4 - Processor State

I knew that programming the flash would probably be tricky and possibly require the core to be halted, so I took some time at this point to do some little helper functions for state manipulation. Halting, unhalting, and restarting the processor are all pretty easy, simply involving writing some magic numbers to magic memory locations.

Step 5 - Programming the Flash

This stumped me for a while until I found the STM32 Flash Programming manual. After that it took some fiddling, but ultimately worked out pretty nicely. The process involves writing a sequence of keys to an unlock register before the control register can be written, then using the control register to erase the whole memory (in theory I could do it page-by-page, but that seemed harder and wasn’t necessary). Then the programming process consists of setting the FLASH_CR_PRG bit to indicate that programming is incoming, setting the AHB-AP to do writes in 16-bit packed mode, and writing the program data to memory starting at 0x08000000.

Step 6 - Optimizing

When I started this step, the script took 11 seconds to program a 3k firmware to the chip. When I finished, it took 1.5 seconds, and a good portion of that is required to avoid overflowing the write buffer (at least I think that’s the reason it errors if I try to decrease the interval between successive words). Those reads are very costly, so the optimizing essentially was just finding clever ways to avoid reading data from the Bus Pirate whenever possible, and only doing it in big blocks when required.

Conclusion

And that was it, modulo some issues with .bin file endianness and me having some trouble getting a decent firmware to compile properly. The code for the programming script, along with some precompiled firmwares which blink the blue LED at different rates, can be grabbed off GitHub, although there is currently no error recovery whatsoever, and only the most basic error detection.