Embedded development: tips and tricks -- seven tips for designing powerful boot loader

　　 Embedded software will never end , The software always needs some adjustments , Add functions or fix errors . Embedded developers can return products to manufacturers for updates , Or you can send technicians to the products . Either way is expensive ! The construction of some products makes it necessary to completely dismantle the system to access the programming port of the microcontroller . The boot loader is the perfect solution for both situations .

　　 Boot loader has become a necessity for almost every embedded system , But unfortunately , They receive little attention . For most developers , The ability to update firmware is an afterthought , Instead of thinking in advance , The result of this oversight is to give up building any update functionality into the system at the last minute . Errors sneak into the system , And due to the lack of testing , There is no doubt that it has entered the field . Yes 7 There are three techniques to follow , To ensure that the boot loader not only updates the firmware , And it's right every time .

　　 skill 1—— Add the boot loader as early as possible

　　 Start the boot loader early in the design , It is best after the proof of concept phase when the project is officially funded . Embedded developers integrate the boot loader into the system as soon as possible , Not only can it be thoroughly tested , You can also limit the changes that may need to be made to the application during the integration process .

　　 skill 2—— Check reset vector

　　 One of the purposes of the boot loader is to put the system into a known state , And decide whether to jump to the application or wait for programming instructions . When the boot loader decides that the application should be started , Jumping to application vectors should not be blind . The system flash memory may have been erased before , Thus, the only position of the reset vector is 0xFFFFFFFF. If you execute this reset vector , What happens to the system ?

　　 Before starting the application , The simplest check that can be performed on it is to ensure that the reset vector has been programmed to a value , That is, it is not erased . A programmed reset vector gives a minimum level of confidence , That is, the program will not jump into the weeds . The following diagram 1 An example is given . Embedded developers even want to get better , Check the boundary of possible effective reset vectors . Boundary checking will help ensure that the reset vector is not only programmed , And is pointed to a valid location .

　　

 

　　 skill 3—— perform CRC check

　　 Resetting the vector check is a good start to verify the existence of the application , But resetting the vector itself does not tell the whole story . What happens if the firmware update is aborted ? The reset vector may have been written to flash , But the application itself is corrupted . Add... To the application CRC Validation is a good way to validate applications . The boot loader can perform fast on application space at startup CRC Check , If the check is successful , The boot loader can assume that the application space is complete .

　　 skill 4—— Lock boot loader

　　 Updating the boot loader on site is an extremely dangerous job . Power failure 、 Stray cosmic rays or dirty appearance may cause the boot loader of the memory to be partially damaged and unusable . As a result, an embedded system is blocked , Until it was saved by more complex programming tools . The boot loader should be a small 、 Simple and robust applications , No function upgrade or error repair is required . Embedded developers should place the boot loader in a protected part of memory , To make sure it doesn't in any way 、 The shape or form is accidentally deleted or overwritten .

　　 skill 5—— Divide flash memory into multiple application slots

　　 Embedded systems sometimes have complex requirements , For example, update the firmware while the application is still running , Or you can restore to the previous version when the update fails . If the flash memory space is not divided into multiple application segments , These requirements will be difficult to achieve . for example , Flash memory space can be partitioned to include boot loader and original firmware in protected memory , Then there are two spare application parts for updating firmware . The boot loader will program one of the spare slots , If it works , You can switch to using the application . In the event of failure , The boot loader can always return to the original application or the application stored in the backup slot .

　　

 

　　 skill 6—— Using handshake protocol

　　 The compiler will generate a representation of the application , The representation is broken down into records . These records can be generated in many formats , But a common feature is that each record represents a smaller block of the application , And include checksums . Developers can create a protocol , Send one record at a time , Verification record , Write it to flash , Then update the tool with the confirmation response . Once the tool receives confirmation , You can send the next record . Use handshake to divide the refresh process into manageable blocks , And when something goes wrong , The system can process it immediately , Not at the end of the update cycle .

　　 skill 7—— Use Delta Generator

　　 The traditional microcontroller boot program will completely erase the application flash memory space during the update process . If only minor changes are made to the software , Updating firmware may waste time . The method often used in large computer systems is to determine the increment or difference between application files , And only update those changed files or memory parts . Embedded developers use Delta The generator can also be used to minimize the time required to update the microcontroller application .