STM32 flashing/programming

[abode091]

Hello,

Talking about bare metal STM32L1xxx MCU, The most confusing thing to me is the programming and debugging interface.

I know that it supports multiple interfaces for programming, but what else is needed for programming?
For example if I want to use SWD, do I need only the 4 pins (SWCLK, SWDIO, GND and VCC) ? This makes no sense, since logically I need a way to make the MCU go into "programming" mode or "debugging" mode, let a lone another pin to reset/restart the MCU.

There's also "Boot loader activation" mentioned in ST documentation, and it mentions BOOT0 and BOOT1, and yet I keep reading that "can be implemented with as few as 4 pins: SWCLK, SWDIO, GND and VCC.".

The docs also mentions "Bootloader identification" which is all about the interfaces used for programming, I don't see USB mentioned.
This is all confusing to me.

My precise questions are:
1) Can I use USB for programming?
2) What other pins do I need other than the interface itself?
3) What is the difference between bootloader and the application/program running on the MCU? When I flash an MCU do I replace the bootloader or not?
4) how to enter the "programming" stage in terms of electrical signals (ex: signal x goes HIGH , signal y goes LOW, etc)

Thanks.

[ataradov]

For example if I want to use SWD, do I need only the 4 pins (SWCLK, SWDIO, GND and VCC) ?

Yes, this is all you need. Reset is optional, although it is better to connect it.

This makes no sense, since logically I need a way to make the MCU go into "programming" mode or "debugging" mode, let a lone another pin to reset/restart the MCU.

SWD gives you access to the whole device memory map. There are no separate programming or debugging modes. You can program the MCU while debugging it, or even while program is running.
And reset can also be triggered though the SWD interface.

There's also "Boot loader activation" mentioned in ST documentation, and it mentions BOOT0 and BOOT1, and yet I keep reading that "can be implemented with as few as 4 pins: SWCLK, SWDIO, GND and VCC.".

Bootloader is not related to the SWD at all. If you use bootloader, you don't need to connect SWD pins at all.

1) Can I use USB for programming?

It depends on the exact part number. Reference manual divided all parts into 5 categories. Lower categories only support USART bootloaders. Higher categories also have USB.

2) What other pins do I need other than the interface itself?

Power and ground. And BOOT0 and BOOT1 need to be configured for the bootloader mode.

3) What is the difference between bootloader and the application/program running on the MCU? When I flash an MCU do I replace the bootloader or not?

Bootloader is in the ROM, you can't replace it. Bootloader can be used with no tools (just a USB to UART adapter).

4) how to enter the "programming" stage in terms of electrical signals (ex: signal x goes HIGH , signal y goes LOW, etc)

Don't worry about that, debugger does this.

[abode091]

Bootloader is not related to the SWD at all. If you use bootloader, you don't need to connect SWD pins at all.

Then how could I do it, and why'd do it?

It depends on the exact part number. Reference manual divided all parts into 5 categories. Lower categories only support USART bootloaders. Higher categories also have USB.

it's STM32L152CBU6A , it supports USB in operation, but does it support it in programming mode?

Don't worry about that, debugger does this.

I still want to read about it, because clearly I still need to understand the process and other terminology like boot, boot loader, programming, and signalling.

But for now, I'm going to put pins for BOOT_{0}, BOOT_{1}, V_{CC}, GND, reset, I2C , USART and SWD pins... because  I want to try programming it via multiple interfaces, for fun and learning purposes.

[ataradov]

Then how could I do it, and why'd do it?

Do what?

it's STM32L152CBU6A , it supports USB in operation, but does it support it in programming mode?

If I'm reading the manual correctly, it is a category 1 device, so it does not have USB bootloader. You need to use either USART bootloader or SWD. Yes, the datasheet fore the device only mentions USART for the bootloader.

I would just use SWD, programmers are dirt cheap.

I still want to read about it, because clearly I still need to understand the process and other terminology like boot, boot loader, programming, and signalling.

SWD interface is very complicated and has a lot of moving parts. There is no description which pins you set and clear.  There is a number of documents that together describe how it works. If you really want to read something about that, start with ARM Debug Interface v5 Architecture Specification (ARM IHI 0031A).

For the bootloader interface, I don't know. It should be described in the ST docs somewhere, but I have never used it, since it is pretty pointless.

Also, for ST parts you need to keep in mind that there are two separate documents. One is datasheet, which is specific to the part and another one is the reference manual, which is common to the family. You need to use both.

[abode091]

Thank you very much for your time and effort.
That was helpful.

[ozcar]

I don’t think there is much about the bootloader in either the data sheet or the reference manual. Look for AN2606 and AN3155.

[Siwastaja]

One source for confusion is that what ST calls a "bootloader" is not a bootloader and has absolutely nothing to do with bootloaders whatsoever. It would be better called "non-erasable, factory-programmed pin-level-activated firmware updater tool", or maybe just "flasher" if that's too long. It differs from the SWD interface by two ways:
* it is less flexible, just for erasing, writing and verifying a firmware; not for debugging
* it can be used with some "more usual" (than SWD) interfaces, depending on product including UART, I2C, CAN, USB, Ethernet, so it is more convenient for "end users" (though, often it's still not what end customers need, in which case you need to roll something of your own)

For development work or factory programming, you can just always choose to use SWD. SWD adapters like ST-LINK V2 (and clones) are not that expensive.

(In reality outside of ST, bootloader actually means a piece of code which always starts first, loads the actual application and boots it. This is optional and orthogonal to flashing/programming.)

[abode091]

Yeah, I spent many hours the last 2 days reading about it, it's basic yet very important concept to master.
For now I'm interesting about the hardware considerations for designing a PCB with STM32 MCU (pins exposed for programmers).
The MCU I'm using supports only USART as communication protocol for programming, so I will need BOOT0 and BOOT1, USART pins, RESET, Vcc and GND, which is a lot, but it seems this MCU doesn't support SWD.

[ataradov]

All ARM Cortex-Mx MCUs support SWD.

I don't understand why you are bothering with this bootloader. The best thing you can do with it is forget that it exists. All of a sudden you don't need so many pins, get programming and debugging over the same pins.

[abode091]

The "system memory boot mode" docs states that the MCU I'm using boot loader activation is activated via USART only.
It mentions: [auote]"After the STM32F030xC devices have booted in bootloader mode using USART2, the serial
wire debug (SWD) communication is no more possible until the system is reset, because
SWD uses PA14 pin (SWCLK), already used by the bootloader (USART2_RX)."[/quote]

That's why I have to use USART. 
I'm not a fan of needing a lot of pins, but based on what I've read I have to. 

[ataradov]

Don't boot it in a bootloader mode. Just forget that it exists. Set BOOTx pins  into a fixed configuration to boot from the flash.

[abode091]

I will need to update the firmware later for sure.
That's why I will need the boot loader, because as I understand it this is the program that will receive the new program, make the checksum test and over write the old program if the new version checksum checks.

Am I missing something here?  🤔

[ataradov]

I will need to update the firmware later for sure.

You can do it though SWD. You can do everything through SWD. Absolute majority of MCUs don't even have a bootloader in the ROM.

make the checksum test and over write the old program if the new version checksum checks.

It will just let you program whatever binary you provide. There may be some check sums on the transport level (UART), but it will not do any application level checksums. Basically the same as SWD.

Am I missing something here?  🤔

Yes, you are missing the fact that you don't need the bootloader to program the MCU.

If you need a bootloader for the application update in the field after they are shipped to the customers, then you will have to create your own bootloader anyway, because nobody in the field will connect USART adapters.

If you need it during development time, then use SWD.

[abode091]

Hmmm, it's interesting, but what did confuse me is that programming with SWD isn't mentioned in the Docs.
OK, I will use SWD, then I will need to develop a boot loader (or use existing one) to make the end user update the firmware using USB...

That's what you mean right?

[abode091]

To use SWD I only need 4 pins  (SWD-IO,SW-CLK,Vcc and GND) right??
No need for ~reset boot0 and boot1 right?

[ataradov]

Hmmm, it's interesting, but what did confuse me is that programming with SWD isn't mentioned in the Docs.

  It is the bare minimum functionality for any MCU, it is understood by default. It is not mentioned for the same reason it is not mentioned that MCU will start working when you apply power.

OK, I will use SWD, then I will need to develop a boot loader (or use existing one) to make the end user update the firmware using USB...

Correct. You will have to make a bootloader that meets your application needs.

To use SWD I only need 4 pins  (SWD-IO,SW-CLK,Vcc and GND) right??

Correct.

No need for ~reset boot0 and boot1 right?

RESET is optional, although sometimes may be necessary if firmware does something that blocks or disables SWD interface.

BOOTx pins can be statically configured for the boot from flash.

[SiliconWizard]

SWD is all you need for development purposes as said above and will be the fastest and easiest way of flashing your MCU once you get it set up.

"bootloader" options for flashing the MCU can be useful in a number of cases, but rarely if ever for pure development.

A number of STM32 MCUs do support USB DFU in ROM (depending on the state of BOOTx pins upon reset). That can be handy as well. If you need USB DFU.

[Siwastaja]

I don't understand why you are bothering with this bootloader. The best thing you can do with it is forget that it exists. All of a sudden you don't need so many pins, get programming and debugging over the same pins.

You can also reach the opposite conclusion from the same arguments: SWD requires as much extra pins as UART. As someone who rarely uses so-called debugger but instead prefers coding practices which give visibility into system (colloquially called "printf() debugging"), I have extensively in the past left the SWD pins unconnected, and instead used the UART, which the projects absolutely needed anyway, so now for programming, I need: 1 extra pin (BOOT0), and no extra hardware at all: the same UART as used by the application, either by USB-UART interface or e.g. Raspberry Pi's pin header UART.

But yeah, if your project does not use UART for communication with a computer which you could also use to program it, then sure it would be two extra pins, and at that point the physical difference (difficulty, cost) between UART programming or SWD programming is negligible, except that SWD gives you much more features.

[Dave]

One source for confusion is that what ST calls a "bootloader" is not a bootloader and has absolutely nothing to do with bootloaders whatsoever. It would be better called "non-erasable, factory-programmed pin-level-activated firmware updater tool", or maybe just "flasher" if that's too long.
<...>
(In reality outside of ST, bootloader actually means a piece of code which always starts first, loads the actual application and boots it. This is optional and orthogonal to flashing/programming.)

You're thinking of bootloaders that are used with complex operating systems. In terms of embedded systems, the term bootloader also encompasses the part of code that allows for firmware reflashing. This terminology is most certainly not unique to ST.

It still is the program that runs at the beginning of system startup, it's just written in factory-programmed ROM. The boot manager part of it is rather minimalistic, though:
Is flash blank OR BOOT0 pin set high?
   -No: Jump to "starting" flash location (where your program starts).
   -Yes: Stay in bootloader, prepare for flashing the firmware (initialize relevant comms, etc.).

[Siwastaja]

You're thinking of bootloaders that are used with complex operating systems.

No, I'm not. It's the same in embedded. Bootloaders that boot first and load an application are extremely common in embedded and can be made very simple (as simple as verifying CRC, set vector table and jump to app, <30LoC total).

In terms of embedded systems, the term bootloader also encompasses the part of code that allows for firmware reflashing.

True: emphasis added by me. The part which boots the application is mandatory for the term to be correct. Additional features make it no less a bootloader. Firmware update feature is one.

Piece of code which does not boot first and does not jump to application, but is just used to update a firmware, is not a bootloader.

This terminology is most certainly not unique to ST.

Mistake being common does not make it any less a mistake. Terminology is important. Be careful though: while not unique to ST, ST's thing is one of the most well known. For example, another well known bootloader, Arduino's bootloader is an actual bootloader.

It still is the program that runs at the beginning of system startup, it's just written in factory-programmed ROM.

This is not true. It does not normally run, only if special mode is enabled by pin strapping.

Is flash blank OR BOOT0 pin set high?
   -No: Jump to "starting" flash location (where your program starts).
   -Yes: Stay in bootloader, prepare for flashing the firmware (initialize relevant comms, etc.).

Any evidence that ST's bootloader code always runs and uses BOOT0 pin as a GPIO or GPIO-like signal sampled by said code? This is news to me and if true, then I stand corrected, it would be a bootloader. BOOT0 pin being software-readable would also open interesting possibilities if it could be turned into an extra GPIO.

[ataradov]

ST documents that BOOTx pin values are latched on the 4th clock of the system clock. They are not regular GPIOs at that time. BOOT1 can be mapped to a GPIO, but BOOT0 remains a dedicated pin.

Although they could potentially be latched to be later analyzed by the bootloader code. But generally, it looks like that there is a true hardware mapping and bootloader does not run at all if not requested.

[SiliconWizard]

ST documents that BOOTx pin values are latched on the 4th clock of the system clock. They are not regular GPIOs at that time. BOOT1 can be mapped to a GPIO, but BOOT0 remains a dedicated pin.

Although they could potentially be latched to be later analyzed by the bootloader code. But generally, it looks like that there is a true hardware mapping and bootloader does not run at all if not requested.

Yes, that's also been my understanding with STM32 MCUs. The MCU directly starts executing code at the beginning of flash if the BOOT pins are not set to enter the bootloader in ROM. It does not go through the bootloader code.
While it probably doesn't make a lot of difference in start times, some other MCUs have relatively "long" start times going through convoluted bootloaders first. That's typically the case for those MCUs which can't directly execute code from flash and download the code to internal RAM and then executes it from RAM.

[Dave]

Any evidence that ST's bootloader code always runs and uses BOOT0 pin as a GPIO or GPIO-like signal sampled by said code? This is news to me and if true, then I stand corrected, it would be a bootloader. BOOT0 pin being software-readable would also open interesting possibilities if it could be turned into an extra GPIO.

I just went browsing through STM32 documents and I can now see what you meant. They indeed call the part that handles just the reflashing "bootloader". They make no mention of what makes the decision at which flash address to start running the processor, so it is likely done completely on the hardware level, without ever touching an actual bootloader.

I work with TI C2000 processors a lot and you can actually step through the boot ROM code with a debugger. The boot selection pins are regular GPIOs that can be remapped if desired. Not the case with STM32.

[Siwastaja]

I just went browsing through STM32 documents and I can now see what you meant. They indeed call the part that handles just the reflashing "bootloader". They make no mention of what makes the decision at which flash address to start running the processor, so it is likely done completely on the hardware level

This (muxing two different constant values into PC depending on a pin) is so trivial to do in hardware that it's certainly not the reason to use built-in software bootloader; TI must have some other reason. Maybe if the non-erasable bootloader resides in flash (and not mask ROM), it allows chip manufacturers to add some code which is guaranteed to always run, for example workarounds for HW bugs they find after the mask set is done and cannot be changed. ST can't do this, so better read the errata for stuff like "BTW, RAM corruption sometimes occur, write this value to this register to disable some buffering feature".

[radiolistener]

For example if I want to use SWD, do I need only the 4 pins (SWCLK, SWDIO, GND and VCC) ?

SWCLK, SWDIO and GND is enough for programming and in-circuit debugging.
But your device needs to have it's own power supply. If you want to program unpowered device, then VCC is also needed.

[TimSmall]

Since nobody else has mentioned it...

When using single wire debug, you should only connect the VCC (from the mcu board to the programmer) if the microcontroller is not already receiving a separate supply voltage.  If the mcu is already getting VCC from elsewhere (e.g. battery, or a separate supply), then you should only connect the other three lines (single wire data, clock, and ground), plus optionally (but recommended) reset.

As it happens, that's the config that I'm using for the STM32F401 (WeAct Studio dev board) which is sitting on my desk at the moment...  The MCU is receiving power over USB, so the debug probe doesn't have VCC connected.

Reset isn't always needed, but can be useful, because it's possible to put the chip into some states where the SWD interface doesn't work (e.g. some power saving sleep states) - so if the swd programmer hardware can also drive the reset line of the target mcu, then it can guarantee that it will always be able to interact with it via SWD and program the part etc.

For programming and debugging, I'm using https://probe.rs/ - but there are many other options of course, and you should use whatever tooling seems most appropriate for your development environment.

[ataradov]

There are not a lot of programmers that provide power. But there are a lot of programmers that use voltage level shifters, so they need target VCC to power the output buffers.

[SiliconWizard]

There are not a lot of programmers that provide power. But there are a lot of programmers that use voltage level shifters, so they need target VCC to power the output buffers.

Absolutely. When wiring a SWD adapter, you should *always* check that, as there is no hard guarantee and you could blow something up if not careful.

Strictly speaking, the standard JTAG connector (both the 20-pin and mini 10-pin one) defines a VTref pin, which is an *input* and serves as the target voltage ref for level shifting and detecting that the target is connected. It should not be an output and provide power to the target.

But many commercial programmers do provide target power as a convenience, which is not compliant (AFAIK) if using a standard JTAG connector, but if they use any other kind of connector, then everything goes and READ the manual.

[zapta]

>> I don't understand why you are bothering with this bootloader. The best thing you can do with it is forget that it exists.

Boot loaders are useful for firmware upgrade by users, but for development, SWD is definitely they way to go.

[ataradov]

No user ever will be using that bootloader. Are you going to ask your users to bust out their USB to UART adapter? Not a chance. Any real product will have a more useful and appropriate update method.

USB MSD bootloader are probably the most user friendly, but that still implies that your product has USB.

ROM bootloaders are useless and are a relic of the past when tools cost $100s for no real reason other than greed.

Typical ROM bootloaders don't include any encryption, so you will also be giving everyone your complete firmware.

[zapta]

My current design has a usb/serial adapter for data link and I provide a binary that flashes it with no extra tools. The binary is a python script converted to a binary using pyinstaller, and is distributed with the other binaries of the app.

https://github.com/zapta/daq/blob/f07ed5b4b486846a237b91fb82ccbbd1ab3feb26/host/src/flasher.py#L1

[ataradov]

This is fine for open projects oriented at technical people willing to run Python from the command line.

This will not work for commercial products where users at best can install an app from the store.

[zapta]

Yes, open code. And the flasher is a single binary so no need to install python. 

I am using this tool to generate the binary from the python sources https://pypi.org/project/pyinstaller/