Using SWD protocoll BitBang to read/write STM32F0 flash

[valentin]

Posted on September 07, 2016 at 01:55

Hi there,

I'd like to build an automated pcb flash & test box. The finished pcb will be inserted into the device and then the device detects the presence of a new board, powers it up, flashes the firmware and tests functionality of the new pcb. After all is finished, either a green or red led light up. Now I am wondering how I could get an STM32 to flash another one via the SWD link? I would probably use a high-density type and store the firmware in its flash so that the unit is completely independent. Any ideas? The boot0 pin is fixed to ground on the pcb. But it must be possible top mimick what the PCB does when uploading a firmware using ST-Link? Thanks!

[Tesla DeLorean]

Posted on September 07, 2016 at 03:11

You'd need to learn the intricacies of the JTAG/SWD protocols, downloading code and data to RAM and executing it to write the flash. In all a rather complicated task if you have no experience of such things.

I'd recommend using the serial connection to the system loader, and use it's protocol to download updates. The protocol is documented and relatively trivial compared to that of the JTAG/SWD method.The boot0 pin is fixed to ground on the pcb. Who designs such things? One can call the System Loader from user code, but it's hard to do that if the device is blank.

[valentin]

Posted on September 07, 2016 at 22:51

Hi clive1,

thanks for your answer. That confirms what I thought initially. About Who designs such things? I did ... now I know better and will change it for the next batch. I'm thinking about using a pull-down resistor so I can have the pin being pulled high from externally during flashing. Only other tricky part is, that there are no more free pins on the micro. Where would you start looking into JTAG/SWD protocols? Any recommended source of information? Cheers! Edit: https://www.silabs.com/Support%20Documents/TechnicalDocs/AN0062.pdf This seems to describe the general process fairly well. The question now would be, how much of that is EFM32 specific and how much of that can be transferred over to the STM32? It looks like most of this applies to the Cortex-M cores in general.

[Tesla DeLorean]

Posted on September 08, 2016 at 01:06

In terms of getting code/data into RAM the method is general to the core, what that code does will be manufacturer specific as you are going to be driving the flash process.

The ST-LINK Utilities has examples of the code downloaded in the form of the binary loaders.

[waclawek.jan]

Posted on September 08, 2016 at 01:36

Some wisdom might be extracted from the

https://github.com/blacksphere/blackmagic/wiki

, some from

http://openocd.org/

... JW

[valentin]

Posted on September 08, 2016 at 02:12

Great, thanks guys. I'll further look into that and then try to set up a bit banging scheme using two discovery boards.

And I mean in terms of me buying the required knowledge from STM and/or signing an NDA - depending on pricing that might be an option, too. There must be at least SOME support from ST's side for their customers to do this? I'd think this use case is not too uncommon, is it? Any idea how I might get in contact with the responsible people from ST? Edit: There's progresss! The above pdf together with the official ARM ADI v5 documentation got me going. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0031c/index.html I successfully managed to do the line init and read the IDCODE by doing manual bit banging. It's quite cool, actually, toggling the clock line by hand and watching the bits come in on an oscilloscpe :) Next objective: Get access to the AHB AP and try a write command...

[waclawek.jan]

Posted on September 08, 2016 at 10:28

Congrats! :)

JW

[valentin]

Posted on September 13, 2016 at 01:01

Update:

I got myself a Logic8 (saleae.com) to have a look at the original ST SWD datastream. After the usual line reset and initialization, right after reading the AHP-AP IDR and setting the transfer size in the Control/Status Word register, the ST-Link does a weird series of reads and writes to some addresses in the 0xE000EDF0 - 0xE000EDFC memory range (the STM32F303 on an STM32F3Discovery). And it continues to do so over the complete sequence. Mostly reading and writing 0x00030003 to 0xE000EDF0. I'm struggling to understand this behaviour. I couldn't find anything about this address range in the ref manual but I could read and modify the contents using the ST-Link tool. Does anybody know what's going on here? I'm basically interested in whether these actions provide any benefit to my goal to manually flash a microcontroller using SWD. Thanks.

[waclawek.jan]

Posted on September 13, 2016 at 08:50

There is world beyond ST's RMs. Debug is part of the ARM core, thus you have to seek information at ARM - particularly, in the ARMv7 Architecture Reference Manual.

JW

[valentin]

Posted on September 13, 2016 at 22:24

Thanks, great advice. Found it:

Debug Halting Control and Status Register (DHCSR) They're halting the core and enabling halting debug (the two LSBs) and checking whether it actually is halted (0x30000). That makes sense! I thought about halting the core by clamping NRST low. This might be more elegant. Will think about it.