In the first three blogs, the application background of IAP remote upgrade, the realization principle of the lower computer, and the basic configuration of the STM32F103 serial port DMA based on STM32CubeMX are mainly introduced . The fourth blog mainly wants to introduce the messages of the upper computer and the lower computer on the Labview side. Definition and communication etc.
When the author first came into contact with the STM32 IAP upgrade at work, there were various confusions to be honest, so this was also the motivation that drove me to write a blog. Many CSDN friends have read " FPGA Basics" and " FPGA 20 A private letter after the column "A Routine" said that the writing is down-to-earth, making it easy for readers to receive and understand. Learning is from not understanding to understanding, from not understanding to slowly understanding, and this process will be very painful when no one guides you.
Of course, the above are all digressions. Let’s think about some problems in the implementation of STM32 IAP upgrade from the perspective of project implementation. In fact, this is also the problem that troubled the author at the beginning. Mainly, they also have many commonalities.
- Does the IAP upgrade need the support of a special host computer? There are different opinions on the Internet. There are many tutorials that use the serial port assistant to select the local bin file and send it;
- What operations do the host computer need to do during the IAP upgrade, can you just send the bin file at one time?
- What operations do the lower computer need to do during the IAP upgrade, is it possible to rewrite the received bin file into the sector according to the hexadecimal number count;
- In the absence of a local display GUI interface, how does the user tell the lower computer whether to jump to the Bootloader or to the Application through the upper computer , and how to switch between the Bootloader and Application ;
First answer the first question. IAP upgrade needs to redesign a host computer. Some serial port assistants do support opening bin files and sending them in hexadecimal data format. If it only meets the teaching experiment, you can use the serial port The assistant sends directly, but in reality, serial communication is unreliable transmission, that is, there may be interference and other errors in the transmission of data. This method of sending bin files without a checksum and retransmission mechanism is obviously unreliable ;
Secondly, to answer the second question, if the upper computer directly sends the bin file to the lower computer at one time, the lower computer needs to receive each byte and then count the data, and then write each flash sector according to 1024 bytes , if the count of the lower computer is wrong during the transmission process, it will not be able to deal with the wrong writing of the flash data, so it is obviously not very safe to directly send the entire bin file to the serial port at one time;
Answer the third question again, assuming that the bin file to be updated each time is different in size, this update is not as large as the previous one, and there may be risks if the data in the flash sector was not wiped clean last time, so it is more recommended Erase completely from the Application initialization address before each IAP upgrade;
Finally , answer the fourth question. Bootloader and Application can be understood as two independent programs. Obviously, STM32 can only run in one of the states at the same time. The value of the eeprom jumps to the Application state, or you can set a timer to automatically jump from the Bootloader state to the Application state if it does not receive an instruction from the host computer within 5 seconds , which can save the material cost of an eeprom ;
The specific implementation principle is that the upper computer sends a 1024- byte bin file message to the lower computer STM32 each time (if the last packet of message is less than 1024 bytes, send as many as there are), and the lower computer STM32 receives each packet of bin After the file is written into the specified flash space, the program control of the upper computer jumps to the Application .
Communication message format between upper computer and lower computer:
The three bytes of 0x7e, 0x7e, and 0x5a are used as a fixed header, and the fourth byte is used as a command code, where the command number includes 0x00 0x01 0x02 0x03 0x04 , that is, the message format is: 3 -byte fixed header 0x7e, 0x7e, 0x5a + 1 Byte command number 0x00-0x04 + 2- byte current message number (command number is 0x01 ) + 2 -byte total message number (command number is 0x01 ) + 1024 -byte bin file content (command number is 0x01 is included) + 2 bytes Modbus CRC check code, the content of the command number is as follows, and the detailed data transmission details are explained below in conjunction with the host computer interface.
0x00 : Check whether the bootloader exists
0x01 : Pack and send the contents of the bin file of the application
0x02 : After sending all the contents of the bin file of the application , notify the lower computer to jump from the bootloader mode to the application mode
0x03 : Check whether the application exists
0x04 : Notify the lower computer to jump from application mode to bootloader mode
Figure 1 IAP upgrade assistant
As shown in Figure 1 is the host computer interface designed by the author, select the baud rate at control 1, and select open or close the serial port at control 2. Click "boot detection" at control 3, the upper computer will send "7e 7e 5a 00 42 b4", if the lower computer STM32 sends "2b 52 49 47 48 54 2e 7a" (ASCII code: +RIGHT+CRC16), it means the upper computer The serial port communication between the computer and the lower computer is correct and the bootloader of the lower computer exists, and other controls on the interface can be operated; if the lower computer STM32 sends "2d 45 52 52 4f 52 cf 0d" (ASCII code: -ERROR+CRC16), it means that the upper computer The serial port communication error with the lower computer and the bootloader of the lower computer does not exist, and other controls on the interface cannot be operated.
When the upper computer determines the existence of the bootloader of the lower computer by clicking the control "boot detection", the control 7 "open file" and the control 8 "send" can be clicked. Click "open file" to open the .bin format locally. file, the size of the .bin file needs to be displayed in the interface display box, and how many packets need to be sent (each packet is 1024 bytes by default), and then click Send to send the binary code packaged message of the .bin file to The lower computer STM32, the upper computer sends "7e 7e 5a 00" + 2 bytes, which packet is the message (the first packet starts counting from 0) + 2 bytes, how many total messages need to be sent + 1024 bytes of .bin file binary data + 2 bytes of Modbus CRC check code, for example, the first packet of message is 1024 bytes, contains a total of 8 packets of messages, then the first eight bytes of the message is "7e 7e 5a 01 00 00 00 07", and so on.
Every time the upper computer sends a .bin file binary message, the lower computer STM32 will send "2b 52 49 47 48 54 2e 7a" (ASCII code: +RIGHT+CRC16) after confirming that it is correct, and the upper computer needs to display xx in the interface display box The /yy packet message is sent successfully. If the lower computer STM32 confirms that there is an error, it will send "2d 45 52 52 4f 52 Cf 0d" (ASCII code: -ERROR+CRC16), and the upper computer will resend the message. The default is the same message Send up to five times, and if more than five times, the upper computer needs to display STM32 remote upgrade failure in the interface display box! If all the messages are sent and the lower computer STM32 of each packet returns correctly, the upper computer needs to display the STM32 remote upgrade success in the interface display box!
After the upper computer confirms that the lower computer STM32 has received all the binary messages of the .bin file, the control 4 "app jump" can be clicked. Click this control and the upper computer will send "7e 7e 5a 02 c3 75", and the lower computer STM32 After confirming that it is correct, it will send "2b 52 49 47 48 54 2e 7a" (ASCII code: +RIGHT+CRC16), and the host computer needs to display that the application jumps successfully in the interface display box! If the lower computer STM32 confirms that there is an error, it will send "2d 45 52 52 4f 52 cf 0d" (ASCII code: -ERROR+CRC16), and the upper computer needs to display application jump failure in the interface display box!
Click "app detection" at control 5, the upper computer will send "7e 7e 5a 03 02 b5", if the lower computer STM32 sends "2b 52 49 47 48 54 2e 7a" (ASCII code: +RIGHT+CRC16), it means the upper computer The serial port communication between the computer and the lower computer is correct and the application of the lower computer exists, and other controls on the interface can be operated; if the lower computer STM32 sends "2d 45 52 52 4f 52 cf 0d" (ASCII code: -ERROR+CRC16), it means that the upper computer The serial port communication error with the lower computer and the lower computer application does not exist.
When the upper computer confirms the existence of the lower computer application by clicking the control "app detection", the control 6 "boot jump" can be clicked, and the upper computer will send "7e 7e 5a 04 43 77" when this control is clicked, and the lower computer STM32 After confirming that it is correct, it will send "2b 52 49 47 48 54 2e 7a" (ASCII code: +RIGHT+CRC16), and the host computer needs to display that the bootloader jumps successfully in the interface display box! If the lower computer STM32 confirms that there is an error, it will send "2d 45 52 52 4f 52 cf 0d" (ASCII code: -ERROR+CRC16),