Understanding the whole picture of interactions between computer and STM32-based modules

Eurorack
#1

Hi pichenettes,

I’m trying to understand all the ways you can talk to your STM32-based modules from a computer.

I’ve been working with STM32 chips for a while now for a project of my own, installing software and debugging via JTAG/ST-Link. I’m also aware of the two-wire SWD as a debug option, but I have not used it personally. Then there’s the method to upload firmware via serial interface. And of course there’s the normal case audio input option you provide for “normal”/non-modder users. Finally, it appears you offer a serial interface (via the DebugPort class) for your own factory uses, which is largely unrelated to the bootloader, but as it uses the same serial pin header on the board I’ll go ahead and ask here.
This is roughly how I think you interact with the board from your computer in each case that I’m aware of:

Mechanism Connector CPU-side

JTAG JTAG adapter openocd
SWD JTAG adapter^ openocd
serial boot serial 6 pin^^ stm32loader^^^
audio panel jack audio interface^^^
serial factory serial 6 pin^^ byte commands to serial port

^ TX/RX wires only
^^ TX/RX/GND wires only
^^^ Device must be reset and starts in bootloader mode

Does that all appear to be correct?

My biggest question relates to how the audio bootloader you install in the factory affects the ability to do stm32loader installs via the serial interface. From what I can tell, this is a function provided by STM’s factory bootloader, which it appears you overwrite. Looking at your audio bootloader code (from Elements in particular), I don’t see it doing anything with a USART to provide that function. Is it the case the stm32loader/serial combo only works where the original STM factory bootloader is installed (e.g., a discovery board), or am I missing some information?

I’m familiar with JTAG and debug code with it regularly on my project. It also sounds like I should be able to do the same via SWD with just two pins on the mini JTAG header. The serial interface Is that correct?

Thanks!

#2

Hi there, let me chime in and try to help you…

> this is a function provided by STM’s factory bootloader, which it appears you overwrite

AFAIK I don’t think you can overwrite STM’s bootloader, it is not written in flash but hard-coded. So STM’s bootloader will load Olivier’s bootloader which will load the actual firmware.

#3

> AFAIK I don’t think you can overwrite STM’s bootloader, it is not written in flash but hard-coded. So STM’s bootloader will load Olivier’s bootloader which will load the actual firmware.

Ah, thanks. I should have realized it’s just another piece of code that’s put in user space and run prior to entering the main code. So, that means all STM32 bootloader functions are retained. Thanks!

#4

The default bootloader provided by STM is acutally much more flexible. IIRC it doesn’t only run off the UART, but also via the USB controller and other peripherals. On boot it cycles through the different peripherals and waits for incoming data on one of them. In the datasheets there is a pretty comprehensive section about what the hardcoded bootloader can and can’t do.

I’d be interested to know why Olivier uses a JTAG adapter in factory programming (I remember I read this somewhere) when the serial option is also available. Maybe speed?

#5

> Maybe speed?

Definitely. JTAG/SWD is an order of magnitude faster than UART.

> IIRC it doesn’t only run off the UART, but also via the USB controller and other peripherals

Pretty cool, I didn’t know that! Apparently, I just checked, it even uses a standard protocol from the USB stack for firmware update, called DFU.

#6

AN2606 is your friend here!

#7

> when the serial option is also available. Maybe speed?

Transfer speed, and uniformity across all modules (some of them don’t have the buttons for using the serial bootloader).