Preliminary design of STM32 IAP bootloader based on TCP

Preliminary design of STM32 IAP bootloader based on TCP daniel_ustb 2015-8-22 Night

Long time no write things, a lot of things happened in the previous period, now finally can calm down to the heart. Stop to look at the past self, all the way, the insistence on technology is how valuable. People's time is limited, as an embedded engineer, the love and curiosity of new technologies will produce the driving force ahead. As to what heights can be achieved, the full view of individual executive and self-discipline, interest is often the best guide.

Recently, the implementation of the next IAP Bootloader is studied, which is very useful in product design. The so-called IAP is an online application program that can be used for remote program upgrades. For example, we have designed a product that is packaged in a delicate shell using a more complex process, or used in a remote scenario, and if you need to modify the program during use, it can be cumbersome and time consuming to write with a burner. Real industrial products will almost always have their own bootloader.

In fact, the realization of their own bootloader in principle is not complicated, is through the interface of the MCU to the external new program files burned into its internal flash, and then to run the new program. Never thought about how to run the same flash inside the two programs without any relationship, bootloader can be achieved. Its core jump code is only three lines:

App_program = (void (*) ()) ((* (__io uint32_t*) (applicationaddress+4));

__set_msp (* (__io uint32_t*) applicationaddress);//Initialize stack pointer

App_program ();//jump to app to execute

Where Applicationaddress, is the application in flash storage address, applicationaddress+4 is the reset interrupt vector address, because the program is to perform the reset interrupt function at the beginning. Before this, use a diagram to illustrate the normal start-up process of the stm32. The following figure illustrates the startup process of arm and how the program is stored in Flash:

For this start-up process, I believe that the picture is already very clear, can also be seen in many documents, I will not repeat it. Of course this is the way the bootloader, and now we have an app that is placed in another area of Flash. You can use the above three lines of code to implement jumps, as shown in the following figure:

The following part is the storage structure of the app and the running process. The process is not to be mentioned. With this idea as a guide, I can complete my own bootloader.

The choice of TCP upgrade method, I think one is the upgrade speed, the second is the use of the original device existing network port, more convenient, in the existing UIP protocol stack based on the implementation of a TCP Server, to receive the host computer sent binary files. When it comes to data interaction, it is necessary to select the corresponding interactive protocol, and more is the 1k-xmodem protocol. Since this is a primary version, it is implemented in the same way that the packet is sent first, and later with the 1k-xmodem protocol, a lot of improvements are made. This simple idea is, after clicking on the download program, before bootloader to shake hands, after successful use of the Internet computer software to read the app bin file, and then divided into 1024-size data packets sent to bootloader, each sent a packet, bootloader write Flash , which only consumes 1K of memory, even for a small stm32 chip can be achieved, rather than a one-time read into the internal RAM before programming flash.

Based on this idea, I have done some experiments and some problems have arisen.

Problem 1,arm received the host computer issued a packet immediately after writing to Flash, and then return the ACK, read and write Flash will take a long time, causing the host computer to send timeouts, causing the resend.

In fact, it is completely possible for ARM to respond immediately after receiving a packet and then write to flash before the next packet is sent.

Second, after a packet of 1024 bytes of data is written to Flash, many of the global variables I define are inexplicably programmed with FF, causing the program to run incorrectly.

I thought for two nights I didn't know why. Later to see the flash function only to find that the original Flash is read and write by block, write data before the entire data block read out, and this function declares a piece of the size of a local array, incredibly 2048 so large. We all know that the local array is placed on the stack of memory, and the Stm32 defined in the startup file is only 1 k in size. When storing a packet of 1024-size data to flash, the stack is too small, causing a leak that overrides the global variables allocated on the heap. This problem can be resolved by changing the stack size in the boot file to Stack_size EQU 0x00002000, which is 8192 bytes.

In this way, my bin file can be stored in flash, I define the first address for 0x08010000, that is, to bootloader set aside 64KBytes of space, my bootloader compiled a total of 26K, enough.

I have a third problem: After writing, I can not carry out. I read the data from the 0x08010000 address in Flash to the bin file by Jlink, and found some data to be wrong.

Programs that go through the jlink by burning apps that are written by the host computer

Originally, the host computer opened the bin file in the wrong way. The host computer software is written in C #, open bin file was first used StreamReader, later found that should use BinaryReader. The original StreamReader is in accordance with the definition of ASC code to resolve, if there is no corresponding ASC code, will appear garbled, and caused some byte dislocation. Read the file to the BinaryReader method, and look at the results of these days.

Next plan: Use the X-MODEM protocol to achieve data interaction, add exception handling mechanism, ensure the reliability of data transmission, and the stability of bootloader.