STM32 flashing/programming - Page 1
Forum section: electronics / general

author: abode091
author_rank: Newbie
timestamp: October 29, 2023, 02:20:57 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 29, 2023, 02:49:06 am
content: Quote from: abode091 on October 29, 2023, 02:20:57 amYes, this is all you need. Reset is optional, although it is better to connect it.Quote from: abode091 on October 29, 2023, 02:20:57 amSWD 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.Quote from: abode091 on October 29, 2023, 02:20:57 amBootloader is not related to the SWD at all. If you use bootloader, you don't need to connect SWD pins at all.Quote from: abode091 on October 29, 2023, 02:20:57 amIt 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.Quote from: abode091 on October 29, 2023, 02:20:57 amPower and ground. And BOOT0 and BOOT1 need to be configured for the bootloader mode.Quote from: abode091 on October 29, 2023, 02:20:57 amBootloader is in the ROM, you can't replace it. Bootloader can be used with no tools (just a USB to UART adapter).Quote from: abode091 on October 29, 2023, 02:20:57 amDon't worry about that, debugger does this.

author: abode091
author_rank: Newbie
timestamp: October 29, 2023, 03:13:01 am
content: QuoteThen how could I do it, and why'd do it?Quoteit's STM32L152CBU6A , it supports USB in operation, but does it support it in programming mode?QuoteI 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 29, 2023, 03:22:47 am
content: Quote from: abode091 on October 29, 2023, 03:13:01 amDo what?Quote from: abode091 on October 29, 2023, 03:13:01 amIf 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.Quote from: abode091 on October 29, 2023, 03:13:01 amSWD 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.

author: abode091
author_rank: Newbie
timestamp: October 29, 2023, 04:00:02 am
content: Thank you very much for your time and effort.That was helpful.

author: ozcar
author_rank: Frequent Contributor
timestamp: October 29, 2023, 04:02:22 am
content: I don’t think there is much about the bootloader in either the data sheet or the reference manual. Look for AN2606 and AN3155.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 29, 2023, 09:48:51 am
content: 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.)

author: abode091
author_rank: Newbie
timestamp: October 29, 2023, 08:49:08 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 29, 2023, 08:51:15 pm
content: 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.

author: abode091
author_rank: Newbie
timestamp: October 29, 2023, 09:11:25 pm
content: The "system memory boot mode" docs states that the MCU I'm using boot loader activation is activated via USART only.It mentions: "After the STM32F030xC devices have booted in bootloader mode using USART2, the serialwire debug (SWD) communication is no more possible until the system is reset, becauseSWD uses PA14 pin (SWCLK), already used by the bootloader (USART2_RX)."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.

author: ataradov
author_rank: Super Contributor
timestamp: October 29, 2023, 09:13:30 pm
content: 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.

author: abode091
author_rank: Newbie
timestamp: October 29, 2023, 09:23:14 pm
content: 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? 🤔

author: ataradov
author_rank: Super Contributor
timestamp: October 29, 2023, 09:28:59 pm
content: Quote from: abode091 on October 29, 2023, 09:23:14 pmYou can do it though SWD. You can do everything through SWD. Absolute majority of MCUs don't even have a bootloader in the ROM.Quote from: abode091 on October 29, 2023, 09:23:14 pmIt 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.Quote from: abode091 on October 29, 2023, 09:23:14 pmYes, 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.

author: abode091
author_rank: Newbie
timestamp: October 29, 2023, 10:09:22 pm
content: 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?

author: abode091
author_rank: Newbie
timestamp: October 29, 2023, 10:16:45 pm
content: To use SWD I only need 4 pins (SWD-IO,SW-CLK,Vcc and GND) right??No need for ~reset boot0 and boot1 right?

author: ataradov
author_rank: Super Contributor
timestamp: October 29, 2023, 10:29:23 pm
content: Quote from: abode091 on October 29, 2023, 10:09:22 pmIt 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.Quote from: abode091 on October 29, 2023, 10:09:22 pmCorrect. You will have to make a bootloader that meets your application needs.QuoteCorrect.QuoteRESET 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 29, 2023, 11:48:41 pm
content: 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 30, 2023, 08:00:36 am
content: Quote from: ataradov on October 29, 2023, 08:51:15 pmYou can also reach the opposite conclusion from the same arguments: SWD requires as much extra pins as UART. As someone who rarely uses so-calleddebuggerbut 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 neededanyway, 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.

author: Dave
author_rank: Super Contributor
timestamp: October 30, 2023, 04:44:18 pm
content: Quote from: Siwastaja on October 29, 2023, 09:48:51 amYou'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.).

author: Siwastaja
author_rank: Super Contributor
timestamp: October 30, 2023, 05:46:05 pm
content: Quote from: Dave on October 30, 2023, 04:44:18 pmNo, 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).QuoteTrue: emphasis added by me. The part whichbootsthe application is mandatory for the term to be correct.Additionalfeatures 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.QuoteMistake 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.QuoteThis is not true. It does not normally run, only if special mode is enabled by pin strapping.QuoteAny 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 30, 2023, 06:28:08 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 30, 2023, 07:40:26 pm
content: Quote from: ataradov on October 30, 2023, 06:28:08 pmYes, 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.

author: Dave
author_rank: Super Contributor
timestamp: October 31, 2023, 12:32:07 am
content: Quote from: Siwastaja on October 30, 2023, 05:46:05 pmI 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 01, 2023, 08:14:28 am
content: Quote from: Dave on October 31, 2023, 12:32:07 amThis (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".

author: radiolistener
author_rank: Super Contributor
timestamp: November 01, 2023, 08:49:21 pm
content: Quote from: abode091 on October 29, 2023, 02:20:57 amSWCLK, 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.

author: TimSmall
author_rank: Newbie
timestamp: November 01, 2023, 08:57:03 pm
content: 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 isnotalready 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 usinghttps://probe.rs/- but there are many other options of course, and you should use whatever tooling seems most appropriate for your development environment.

author: ataradov
author_rank: Super Contributor
timestamp: November 01, 2023, 09:07:35 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 01, 2023, 09:27:08 pm
content: Quote from: ataradov on November 01, 2023, 09:07:35 pmAbsolutely. 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.

author: zapta
author_rank: Super Contributor
timestamp: November 04, 2023, 05:29:03 pm
content: >> 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.

author: ataradov
author_rank: Super Contributor
timestamp: November 04, 2023, 05:39:44 pm
content: 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.

author: zapta
author_rank: Super Contributor
timestamp: November 04, 2023, 08:19:55 pm
content: 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

author: ataradov
author_rank: Super Contributor
timestamp: November 04, 2023, 09:25:08 pm
content: 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.

author: zapta
author_rank: Super Contributor
timestamp: November 04, 2023, 10:12:03 pm
content: 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 sourceshttps://pypi.org/project/pyinstaller/