1320 _stm32f103 burn write programs using a serial port

All learning summary: GitHub - GreyZhang/g_stm32f103: some hack for stm32f103

Before, in order to quickly upgrade the software for program testing and facilitate hacking, I tried to transplant a serial port-based BootLoader.The porting is easy and smooth, but it is found that the BootLoader is not very streamlined, and it still occupies a lot of resources.Of course, a big reason may be caused by using the driver code of the SDK.

In the past two days, try to get in touch with the STM32 version of the Arduino open source project.Nothing has started yet, I simply installed the IDE and saw a prompt, which made me think that maybe STM32F103 should have a way to directly use the serial port to burn the program by default.

Such a Boot mode description can be found in the STM32F103 manual. When the second mode is selected, it will boot directly from a piece of system storage.This system stores and stores a program solidified by the chip factory. This program itself supports serial port and other modes for program programming.

Here is a further introduction to the role of this system storage.When ST is mass-producing chips, it will burn a special program here, which can be used to support Flash upgrades.If the serial port is used, then the clock of the UART still comes from the internal clock.Therefore, it will not have any special relationship with the crystal oscillator.Of course, this mode also supports other communication methods, but the serial port should be the most cost-effective one.However, I have some doubts. Another F103 MCU in my hand has some problems when the debugger recognizes the device ID.From the network information, it should be a clone chip. I wonder if such an MCU still supports such a function?

This is the process of using the above mode to call ST's programming host computer for programming.That's what I saw when I tried the STM32 version of the open source Arduino solution I mentioned earlier.

It is worth mentioning, by the way, this mode of booting and burning.If you want to enter this startup programming mode, you must first configure the pin levels of BOOT1 and BOOT0, and then you need to perform a reset operation, so that the MCU will enter the corresponding mode.At this time, if you directly use the serial port to program the program successfully, it will run directly.However, if we want the program we burned to work normally, we should modify the configuration of BOOT1 and BOOT0 again, otherwise the software will enter the program stored in this system again when the software is reset.Through the actual test, if you want to debug all the time, you can do it without resetting. When the programming is finished, there is a direct jump to the user flash execution process.But if it is reset directly without modifying the BOOTx configuration, the software will no longer run.

Next, I refer to the command script in Arduino to do a programming directly through the command line mode.Burn the serial BootLoader in front of me, and by the way, burn a LED flashing program to test whether the burning function is OK.

From here, the burn appears to be successful.BootLoader is also successfully burned and started, but whether the effect of startup is correct still needs to be verified.The current serial port is occupied, and it is not easy to monitor temporarily. I need to switch to a new monitoring tool and restart the program.The next operation is naturally the one mentioned above, first configure the two BOOT pins, and then reset.

From the effect of the prompt, BootLoader programming is successful.The test is actually repeating the content of the previous study notes, so I won't test it for the time being.After programming an LED flashing program, I saw the LED flashing.It seems that the several processes involved this time are all OK.