1. Definition of SOTA
SOTA (Software updates Over The Air), means that without connecting the programmer, through CAN, UART or other communication methods,Implement application updates.
When performing SOTA, it is necessary to erase the old application program and write the new application program. The conventional implementation method needs to develop the BootLoader program and the APP program separately. When the MCU is powered on, the BootLoader is run first, and the BootLoader chooses whether to jump to the APP and whether to update the program according to the situation. Specifically, there are the following methods:
Solution 1 : When updating the program, the APP receives the updated data and temporarily stores it in Flash, and thenChange the APP update flag; When the MCU restarts, the BootLoader checks the update flag, and if it is valid, erases the old APP, and then writes the new APP data temporarily stored in Flash to the APP running address. The advantage
of this solution is that the reception of the update data is completed by the APP, and the BootLoaderNo communication protocol stack required, the amount of code is smaller, and when the data transmission is interrupted, the original APP will not be damaged.
The disadvantage is that additional Flash space is required to temporarily store update data.
Solution 2 : In BootLoaderBuilt-in communication protocol stack, when updating, first send an instruction to the MCU to jump to BootLoader, then erase the old APP, and write it directly to the APP running address of the Flash while receiving the new APP.
The advantage of this solution is that no additional Flash temporary storage data is required.
The disadvantage is that the BootLoader code is more complicated, and if the data transmission is interrupted, the old APP will not be restored. This solution is more suitable for MCUs with smaller Flash capacity.
Option 3 : Combine Option 1 and Option 2, that is, in the BootLoader programBuilt-in communication protocol stack, when updating, first send an instruction to the MCU to make it jump to BootLoader, and then when receiving the updated data, use the method of scheme 1,Temporarily store data in Flash first, After all the data is received, the old APP will be erased and the new APP will be written.
This scheme combines the advantages of scheme 1 and scheme 2, and can realize program update in the state of no APP or APP damage .
The disadvantage is that the BootLoader code size is larger, and the Flash space takes up more space.
Solution 4 : Divide two areas of the same size in Flash, divided into A area and B area, both are used to store APP, but only one area of APP is valid at the same time, and a flag is set to mark its validity. In the initial state, first write the APP into the A area, and when updating, write the new APP into the B area, then erase the APP in the A area, and update the validity flag status of the two areas at the same time. In the BootLoader, it judges which area the APP is valid, and then jumps to which area to run. The advantage
of this method is that there is no need to copy the APP data repeatedly, but the biggest disadvantage is that the APP programs in the AB area have different running addresses and need to be compiled separately, which greatly reduces the applicability.
After the above analysis, it can be seen that each scheme has its advantages and disadvantages. For MCUs with small Flash capacity, scheme 2 is usually adopted , because there is not much space to temporarily store APP update data. However, for MCUs with a large Flash capacity, it is usually necessary to temporarily save the APP before updating it to prevent the interruption of data transmission and make the APP unusable . The above schemes 1, 3 and 4 can be realized, but they are not perfect. The SOTA mechanism of AURIX’s TC3XX series is more similar to Solution 4, but its Flash supports two address mapping methods, so that it is not necessary to distinguish between AB and AB areas when compiling the APP, and the same address can be used, thus avoiding the flaws of Solution 4 and providing us with an optimal SOTA solution.
2. MCU flash address mapping method
Taking the Flash of TC397 as an example, the PFlash used to store the program codeStandard address mapping method(Standard Address Map) is as follows, PF0-PF5 in the table represent 5 blocks of Flash in the physical sense.
The second address mapping method is called Alternate Address Map. As shown in the table below, the address range of PF0-1 in standard mode is now mapped to PF2-3, and the address range of PF4 is mapped to PF5.
3. Functional description of SOTA
When the SOTA function is activated, PFLash is divided into two parts, one part is used to store executable code (active bank), and the other part can be used for reading and writing (inactive bank).When the APP is updated, the two parts are exchanged, that is, the above two address mapping methods are switched.. Use PF0-1 and PF4 as the active bank in the standard mode, hereinafter referred to as group A, use PF2-3 and PF5 as the active bank in the alternate mode, hereinafter referred to as group B, you can realize the above solution 4, and you can write the same APP program and run it at the same address.
⚠️ Note that all NVM operations are performed through the DMU using the physical system address of PFLASH, that is, NVM operations always use the standard address mapping , regardless of which address mapping is chosen to be used. ("NVM operation" is a term used for any commands for FLASH, such as program, erase, etc., but does not include reading and executing code.) The parameters related to SOTA address mapping are configured in UCB (User Configuration Block) in Flash. After configuring in UCB, the configuration
will be updated only when the MCU is reset next time.
4. SOTA configuration method
4.1 Configuration parameters of SOTA
(1) SOTA Mode Enable
This parameter determines whether to enable the SOTA mode. It is configured in SWAPEN in the register Tuning Protection Configuration, and is defined as follows:
(2) Bank Swap
configures which address mapping is used in the SOTA mode in the UCB_SWAP area.
The UCB_SWAP area includes the following contents:
the first four are the most important, which are introduced as follows:
① MARKERLx (x=0-15)
MARKERLSWAP is to mark whether to use standard address mapping or Alternate address mapping.
② MARKERHx (x=0-15)
The corresponding entry address of MARKERLx.SWAP is stored in MARKERH, which is used for verification.
③ CONFIRMATIONLx (x=0-15)
CONFIRMATIONL is the confirmation code, and the above MARKERLx.SWAP is valid only after writing the fixed 0x57B5327F.
④ MARKERHx (x=0-15)
The entry address of the corresponding CONFIRMATIONLx.CODE is stored in MARKERH, which is also used for verification.
4.2 Initial configuration of SOTA
The initialization state is to use standard address mapping, and SOTA mode is not enabled at this time. Follow the steps below to enable SOTA:
① Use a programmer to program APP into the group A address of PFlash.
② Write 0x00000055 to MARKERL0.
③ Write the system address of MARKERL0 to MARKERH0.
④ Write 0x57B5327F to CONFERMATIONL0.
⑤ Write the system address of CONFERMATIONL0 to CONFERMATIONH0.
⑥ Set the SWAPEN flag in UCB_OTP0 to Enable.
⑦ Restart the MCU.
After the above steps, the MCU has entered the SOTA mode, and the steps ②-⑤ are to enable the standard address mapping. The following flowchart is given in the manual for reference, and some encryption and decryption steps are skipped here:
4.3 Subsequent configuration of SOTA
The above is the configuration when SOTA is enabled for the first time. Let's take a look at the configuration after SOTA is enabled.APP updateSteps:
① Write the new APP into the inactive part of PFlash, that is, the Inactive Bank mentioned above, and check the accuracy.
② If a new APP is written into group B, write 0x000000AA to MARKERLx.SWAP to enable the Alternate address mapping mode; if a new APP is written to group A, write 0x00000055 to MARKERLx.SWAP to enable the standard address mapping mode. (x is a value from 0 to 15, starting from 0 and increasing upwards. From the above, we can see that UCB_SWAP can store up to 16 sets of flag values, and then erase and rewrite when it is full.) ③ The configuration of MARKERHx.ADDR, CONFIRMATIONLx.CODE and CONFIRMATIONHx.ADDR is the same as above
.
④ Write 0xFFFFFFFF to CONFIRMATIONL(x-1).CODE again to invalidate the last set of UCB_SWAP values. Writing a value of all 1s to PFlash again will not cause PFlash operation error.
The following flow chart is given in the manual for reference:
