Firmware stm32 via UART. STM32 is very simple Stm32 where to get ready-made firmware

The easiest and most affordable way to flash STM32- by using bootloader, in this article we will look at how to do this using the example of a board miniSTM32F103V.

First, let's understand what is bootloader or whatever it is called loader. Loader- it's just a program that is stored in a specific section of memory and can overwrite the flash microcontroller. It is sewn up during the production of the chip and cannot be changed in any way. In order for the microcontroller to enter this section of memory, you need to output BOOT0 pull up to power, and output BOOT1 to the ground. On the board, these two pins are located near the usb connector, and the pull-up is carried out using jumpers.
Below is a table that determines from which memory area the microcontroller will start after a reset, depending on BOOT0 And BOOT1.

Suppose we have installed jumpers, now we need to transfer the hex file with the firmware to the bootloader, we will transfer it by uart, for this we need a converter usb uart.

I have such a converter made on the basis of a microcircuit FT232RL using a thin tip for a soldering station, soldering it is very simple. The sealing method is as follows, first you need to grab a leg from two opposite angles, then when the microcircuit is fixed, solder the rest of the legs with a soldering iron or a hairdryer. And the final touch, once again we solder the legs, which were soldered first, in order to remove mechanical stress from them.

We connect the adapter usb uart to the computer and depending on which chip it is made on CP2120 or FT232, install the appropriate drivers. After that, it should be defined in the system as COM_PORT.

Now let's connect our adapter to the board, connect the RX output of the adapter to the output MCU_TxD, and the output of TX with the output MCU_RхD. The topology of the board that the seller sent is slightly different from the one in the top picture, the pins for the firmware are displayed separately and are marked with red arrows.

Next, you need to download a program with which we will contact the bootloader, it is called FLASH LOADER DEMONSTRATOR.

After installing the program, select the com port under which our adapter was defined usb uart and press the NEXT button, the speed will be determined automatically. If the controller is read-protected, then protection can be removed by pressing the "Remove Protection" button, while the flash memory will be erased and, accordingly, all the data that is written in it is lost.

If the controller is not protected, the window shown below will appear, in it we press the NEXT button.

In the next window, you need to choose what we want to do: read / write the flash of the microcontroller, erase it, prohibit reading / writing, we are interested in writing, for this we select the file we want to upload and press NEXT.

Well, here we have reached one of the most interesting stages - how to upload the finished firmware to the controller and finally revive our piece of iron.

In fact, you can flash STM32 controllers in different ways, but we will consider the simplest firmware option - via a serial interface using the proprietary Flash Loader Demonstrator utility. This utility is completely free and can be downloaded from both the official and .

As we said earlier, the bootloader is sewn in the system memory area of the controller. It is he who allows you to write the firmware to flash-memory via a serial interface.

The bootloader is described in detail in the AN2606 document (CD00167594.pdf), and the protocol it uses is in the AN3155 document (CD00264342.pdf). This is for those who want comprehensive information, and we will consider the firmware process through the bootloader in brief.

First you need to download and install the Flash Loader Demonstrator utility on your computer.

So, the Tx leg of the controller must be connected to the Rx leg of the converter, and the Rx leg of the controller to the Tx leg of the converter. In addition, the controller must be powered and provide the desired levels on the legs BOOT0 (pin 44), BOOT1 (pin 20). To start the bootloader, which is located in the system memory, the BOOT1 leg must be pulled to the "ground", and BOOT0 to the "power" (plate on the right).

It is better to do a pull-up for BOOT0, BOOT1 not hard, but with jumpers, so that you can easily select boot modes (for example, by switching to flash boot mode after uploading the program, you can immediately test this program).

The connection diagram is shown below.

The parity and the number of data bits are already configured as needed, the speed can be changed - the controller automatically adjusts to the selected speed during the initialization of the exchange, you need to select the com-port that was created when connecting the USB-to-COM converter to the computer (our converter creates when connecting virtual com-port, which completely imitates a real hardware one). After everything is set up, click "Next".

The fact that everything is fine and it was possible to connect to the controller, we will be informed by a green traffic light on the next page. If the connection is not established, we will not be allowed to enter this page at all, saying that the controller is not responding.

When a connection is established, the program will automatically determine how much flash memory the controller has and whether this memory is read-protected. By pressing the “Remove protection” button, protection can be removed, but the contents of the flash will be erased (the previous firmware written there will be destroyed). We press "Next".

In the next window, we are prompted to select the type of stone to be programmed (although it is not clear why - it is automatically determined anyway), and they also show the PID, flash memory card, and bootloader version for our stone. Just click "Next".

In the next window, you need to choose what we actually want to do with our controller. The following options are possible here: Erase (erase), Download to device (download firmware to the controller), Upload from device (read firmware from the controller), Enable / Disable Flash protection (enable / disable flash memory protection), Edit option bytes (change option bytes). Accordingly, if we want to upload the firmware, select Download to device, then click on the square with three dots and select the file with the firmware to be uploaded in the explorer, and then click “Next” again.

On the next page, a progress bar will appear at the bottom, which will show the progress of the download procedure. After all the firmware has been downloaded to the controller, this progress bar will turn green and it will say in white letters: “Download operation finished successfully” (the download operation was successfully completed). After that, you can click the "Close" button and close the Flash Loader Demonstrator

That's it, now for the flooded program to start executing, we just have to configure the controller to boot from flash (BOOT0 = 0, BOOT1 - any level) and reboot it.

This Arduino clone offers a special bootloader that allows you to upload firmware via USB, without the use of external components such as ST-Link or a USB-UART adapter.

Today I needed to work with a bare controller from under CooCox and without stm32duino. But here's the problem. Even a simple blinker with a light bulb poured through this bootloader does not work.

Let's figure it out. Perhaps my calculations will seem banal to someone. But I'm just starting to study STM32 controllers and I killed at least half a day to find a problem. Suddenly this article will reduce someone's development time.

I have nothing against ST-Link and other debuggers. But in my finished device it will not be, but it will definitely be USB. Why not immediately lay down the ability to update the firmware via USB? Personally, I find this method convenient. especially since I still have a cord connected through which power and USB Serial are supplied.

Let's see how the bootloader works. To begin with, on the example of AVR controllers. Why did I remember him? I was moving from Arduino and subconsciously expected the same behavior. But in STM32 everything turned out differently. Therefore, I want to talk about the difference between these two microcontrollers.

So. IN AVR microcontrollers ATMega bootloader can reserve a certain amount of memory towards the end of the flash. Using fuse bits, you can control from which address the program will start. If there is no bootloader, the program starts from address 0x0000. If there is a bootloader, it starts from some other address (say, in ATMega32 with 0x3C00, if the bootloader size is set to 2k).

When the bootloader has done its work, it transfers control to the main program from address 0x0000. Those. the program always starts at address 0x0000. The compiler and linker work with the assumption that the code will be located at the beginning of the address space.

In STM32 microcontrollers, everything is different. All programs start at address 0x0800000. The bootloader is nothing special. This is the same program that starts from the same starting address. During operation, the bootloader can receive firmware (via USB or UART, read from a USB flash drive, receive from a satellite, get it from subspace, whatever ...) and write it to addresses higher than the bootloader itself is located. And, of course, at the end of your work, transfer control to the main program.

So, when compiling the firmware, you need to know where the bootloader will write the firmware and adjust the addresses accordingly.

That's all with theory. Let's move on to practice. Below step-by-step instruction how to screw USB bootloader to microcontrollers of the STM32F1xx series, and maybe to some others too.

There are, however, some restrictions on circuitry. Here, unfortunately, I am not strong. YTP needs a 1.5k pull-up resistor for the PA12 port (aka USB D+). This allows the bootloader to right moments time to connect and disconnect from USB.

Instruction:

Download github.com/rogerclarkmelbourne/STM32duino-bootloader. The STM32F1binaries directory already has a package of compiled bootloaders for different boards. The index at the end of the file name indicates where the LED is connected. In the case where the LED is connected to pin C13, I used the generic_boot20_pc13.bin file.
Let's flash. Yes, you will need a USB-UART adapter, but you can probably use a debugger
Now the microcontroller is ready to be flashed via the USB bootloader. But you still need to fix the firmware itself. And you need to do 2 things:
- Specify the linker's starting address. In CooCox, this is done in the project settings, Link tab, Memory Areas section, IROM1 Start Address. The bootloader occupies the first 8 kilobytes, so the starting address of the firmware will be 0x0800000 + 0x2000 = 0x08002000. The Size field should probably also be reduced by 8k
- Somewhere at the beginning of the program, before initializing the periphery, make a call to NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x2000);
The firmware filler is possible. In the tools directory, look for a script called maple_upload. I used only the Windows version - maple_upload.bat
Run like this:
"maple_upload.bat" COM20 2 1EAF:0003 "PathToFirmware.bin"
Instead of COM20, you need to substitute your port where the microcontroller is attached.

The filler is a very delicate thing, it does not like relative paths. so the path to the firmware must be specified in full.

1EAF:0003 is VID and PID

2 is the AltID parameter, which indicates that the firmware should be uploaded at 0x08002000 (read)

A few more nuances. Before uploading the firmware, you need to run the bootloader. The easiest way is to press the reset button. After that, the bootloader will start and wait a few seconds for the firmware. If no one is running maple_upload at this point, the loader will pass control to the main firmware.

This may cause inconvenience. If the microcontroller shuts down and hangs, then it no longer listens to the port. Therefore, he cannot hear the key sequence and reboot into the bootloader. Then only reset to help.

That's all. I hope my article will shed light on how the bootloader works in STM32 and how you can upload firmware via USB port. Unfortunately, the entry threshold is still high, but suddenly my article will help someone overcome it.

Let's say you have launched your device on the market and are afraid that someone will start copying it ... Indeed, it is enough to connect the programmer to our device and read the firmware, for example, through the ST-Link Utility ( Target ⇒ Connect).

Of course, you can just tear off the legs of the microcontroller ... but the developers of ST Microelectronics offer a better alternative. All MKs have a read out protection system. Its essence is extremely simple - if a special register (Option bytes) is set certain value- then the ability to debug and read the firmware is disabled. In this mode, you will also lose the ability to flash the MK. Of course, this protection can be disabled by changing the value in the Option bytes register, but in this case, the program's memory will be overwritten, which means that no one will be able to copy it.

You can change the value in the register using the same ST-Link Utility, Target ⇒ Option Bytes… ⇒ Read out protection ⇒ ENABLE.

Disable, respectively, can be in a similar way. This is not very convenient if there are a lot of devices. You can enable protection programmatically.

To implement protection, it is convenient to use standard library peripherals, specifically stm32f10x_flash.c contains the function we need. The register itself, as well as working with flash memory, is described in the document. However, before that, let's remember how protection for multiple inclusion of header files is implemented. We used such preprocessor directives as:

#define - the directive tells the preprocessor to replace the line in the file, however, if the argument (what is at the end) is not specified, the identifier itself (what is in the middle) remains in the system and can be checked by other directives (i.e., you can write a condition, with which certain code will be executed or vice versa);
#ifndef - the directive can be read as "if not defined", but another #ifdef - "if definitely" is more suitable for us;
#endif - a directive indicating the end of a condition.

Let's create an identifier that will say that this assembly is final. Bye given string commented out - code placed between #ifdef and #endif will not be executed.

//#define RELEASE

At the final assembly, just uncomment the line and flash the device.

#ifdef RELEASE // code here #endif

And now to the point. We have already figured out how to work with the internal flash memory of the microcontroller. Before writing the protection bits, you must unlock access to the memory, then you need to perform the necessary operations and again block access. It turns out the following:

#ifdef RELEASE #warning "Protection is ON. Debug is OFF" if (FLASH_GetReadOutProtectionStatus() == RESET) ( FLASH_Unlock(); FLASH_ReadOutProtection(ENABLE); FLASH_Lock(); ) #endif

Some of the stm32 microcontrollers support the USB DFU protocol (their list can be found in app note AN3156), firmware can be uploaded to such MK via regular USB, using for example DFuSe demo from ST, or open source dfu-util. With this option, everything is clear and I will not describe it.

For the same MK (in particular, the one used in the BluePill board - STM32F103C8T6), which are deprived of DFU support, one way or another you need a programmer, for example ST-Link V2 Mini

Device pinout:

Connecting to the board is simple:

ST-Link STM32F103C8T6 3.3V --- 3.3V GND --- GND SWDIO --- DIO SWCLK --- DCLK

You also need the ST-Link Utility, you can download it from the official website st.com - link. When connecting for the first time, it would be nice to update the firmware of the programmer itself. Select ST-LINK -> firmware update, if a more recent firmware is available, then there will be something like this:

Select Yes >>>>, the firmware is updated.

Next, open the firmware file itself, and select Target -> Connect. Information about your MK will also appear in the utility status window - this means that the programmer is connected correctly and the utility can contact the MK. Example:

Then you need to do a complete cleaning of the chip, select Target -> Erase Chip

If, for example, my firmware from the pedal and button controller post has already been uploaded and needs to be updated or reloaded, then the programmer will not be able to connect to the board so easily (because I use SWD pins like regular GPIOs). In this case, there are two options:

rearrange both yellow jumpers. In this case, the board will be loaded immediately into your internal bootloader
you can do the so-called Connect under Reset. For him, the sequence would be:

in ST-Link Utility select Target -> Settings
in Reset Mode select Hardware Reset
press and hold the Reset button on the board
click OK in ST-Link Utility
release the reset button on the board

PS. If you have a SMT32F4Discovery developer board, it already has a programmer in it and can also be used to flash another board. In this case, you need to use the SWD connector on STM32F4Discovery and remove both CN3 jumpers. The SWD connector has the following pinout: