2
\$\begingroup\$

I'm making a PCB for a personal project using the STM32L031K6T7 microcontroller. It looks like this uC has a bootloader that can be used to reprogram the flash program mem through UART or SPI. It also has SWD pins.

So, does that mean I have two entirely separate but equally valid methods to program this uC if I want? I understand I'm able to interface to SWD using my j-link debugger, but how would I interface to the bootloader method?

My guess is that I'd need a device to interface between my computer's USB and the UART or SPI bus of the uC, but I'm not 100% sure. And then I'm wondering if I have to worry about what would happen if I had the SPI bus populated with other devices, and then I tried the bootloader method to program it. Wouldn't the programmer device need to be the SPI master in order to start communications with the uC as a slave?

\$\endgroup\$
  • \$\begingroup\$ You might start with: AN2606 STM32 microcontroller system memory boot mode. See page 15 for "Related Documents". \$\endgroup\$ – Tut Jan 23 '17 at 19:48
  • \$\begingroup\$ Ah. That makes much more sense. Looks like the bootloader acts as a SPI slave when in that mode. So I guess I can have other devices on the SPI bus, since I'll just activate the select pin of the bootloader only when I need it. And it definitely seems like I'll need a device to interface between USB and SPI. \$\endgroup\$ – orngnr Jan 23 '17 at 20:00
2
\$\begingroup\$

Yes. Many STM32 devices come with built-in bootloader. See the documentation on how to trigger it. This is often done by tying a pin high during power up.

You will also need to read the datasheet on how to use the SPI and UART in bootloader mode.

So yes you can program the device either using the bootloader or using SWD.

SWD is also be used for debugging the device (e.g. single step through code, examine memory) whereas the bootloader is only for loading a program.

\$\endgroup\$
  • \$\begingroup\$ Fantastic. Thanks for confirming what I thought I understood about it! So it looks like some microcontrollers have bootloader memory that's clean when you get it, so they write their own bootloader to help program the flash? \$\endgroup\$ – orngnr Jan 24 '17 at 5:06
  • \$\begingroup\$ That is correct. For example all the Microchip PICs (as far as I know) do not have a built-in bootloader; it must be programmed the first time with one. Keep in mind that they do have services that will ship you pre-programmed ICs with your custom .hex file. This is quite useful for high volume production. \$\endgroup\$ – Vince Patron Jan 24 '17 at 18:04
1
\$\begingroup\$

SWD is a 4 wire JTAG interface with no hardware reset. JTAG has more wires but also has reset line to reset the processor using a hardware line (the processor could get into a mode where you might not be able to reset the processor with a software debug command, at which point you would have to power cycle it. ) The JTAG interface can also be run in a SWD "mode" where your only using 2 wires for communication.

There are several ways to program a STM32, (External Flash, USB, External ROM) but they require code to be running on the procesor so initially you'll need a bootloader and programming. You'll need the SWD or JTAG for debugging anyway.

\$\endgroup\$
  • \$\begingroup\$ What do you mean when you say that there's several ways to program the STM32 that require code to be running on the processor? I was under the impression that JTAG/SWD could be used to program the uC regardless of what program is currently loaded in the flash? And then for the bootloader option, the program in the flash isn't even being run- instead, the bootloader code in system memory is being run. So I'm not sure what you mean when you say I'll need "bootloader and programming". Thanks! \$\endgroup\$ – orngnr Jan 23 '17 at 21:47
  • \$\begingroup\$ A bootloader requires programming the onboard flash on the STM32, it can be a one time program and then you can load your program from whatever source you want, but to load the bootloader you need a JTAG\SWD \$\endgroup\$ – Voltage Spike Jan 23 '17 at 22:00
  • \$\begingroup\$ Ohh, okay, I think I see what you mean now. So in this case, the STM32 chip I'm looking at comes with a pre-programmed bootloader (I believe). I guess that leaves me to program the program flash mem with either method then. \$\endgroup\$ – orngnr Jan 23 '17 at 22:04
1
\$\begingroup\$

I know it's old but I'm seeing things that can confuse a newbie.

The "bible" for dealing with the various STM32 embedded boot loaders is ST-Micro's AN-2606, "STM32 microcontroller system memory boot mode", it's updated as a new series are released. As of this writing, it was last updated in Oct 2019(meaning last month).

Next, ALL STM32 chips have at minimum, an embedded serial boot loader. It is factory ROM and can not be erased. This means that an external interface(JTAG/SWD) is not required to program a STM32at in most instances. Watch out for possible mismatches in voltage.

AN-2605 describes the various methods of invoking a system boot loader. The number of available interfaces ranges from a single USART interface in some of the early STM32F1 series to the H7's, which are monsters, with a total of 12 interfaces, 3 USART, 3 I2C, 4 SPI, 1 USB(DFU) and 1 FDCAN.

You can of course ignore all of this and use a JTAG/SWD adapter to program the MCU. These have the added bonus of allowing you to also debug your work.

\$\endgroup\$
  • \$\begingroup\$ One would have to be EXTREMELY space constrained to justify not bringing out the SWD pins to at least tiny test points or vias. But then, not bringing out a UART for debug messages is also a mistake to be avoided on all but the tiniest designs. Yes, messages over SWD are in theory a possibility; in practice a UART is usually better. \$\endgroup\$ – Chris Stratton 2 days ago
  • \$\begingroup\$ Well the main thrust of the prior answers and the OP were concerning boot loaders with some stuff I thought was a little flaky here and there. I've played with various boot loaders, but 99% of the time I use SWD for my programming and debugging, using SWO and/or serial for getting state information out, I prefer printing to SWO from a low priority thread. One of the reasons I avoid using the Cortex-M0/M0+'s for development is their lack of SWO output. \$\endgroup\$ – GB - AE7OO 2 days ago
  • \$\begingroup\$ No need to avoid the M0's - there's a UART mapped to one of the SWD pins, provided you have brought out the reset and have an non-fake SWD adapter that can actually drive the reset line, simply wait a second or two after reset then remap the SWD pin to UART TX and start dumping data. \$\endgroup\$ – Chris Stratton 2 days ago
  • \$\begingroup\$ Since I use a Black Magic Probe for all of it, it is simple to hook up both serial and SWO to one of the VCPs. With a couple of easy patches, the BMP understands SWO output just fine. So with GDB in one window, Putty in another and my favorite SWO reader in yet a third, I can get just about any information I want. \$\endgroup\$ – GB - AE7OO 2 days ago
  • \$\begingroup\$ I'm talking about SWO, a UART does not have the same abilities. SWO is connected deep in the onboard debug hardware, not near the same. As an example you have the choice of either async or Manchester output with SWO. \$\endgroup\$ – GB - AE7OO 2 days ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.