Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What is the pain point of App switching in OTA upgrade

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

Shulou(Shulou.com)06/01 Report--

What this article shares with you is about what is the pain point of App switching in OTA upgrade. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

OTA upgrade design is an unavoidable topic for almost every mass production customer. After product release, it is inevitable to do firmware (App) upgrades to fix bug or add new features. Upgrading App is a hassle, because it is not handled properly, and the App is damaged so that the product cannot be started, and the product is easy to turn into bricks. Even if the changed bricks can be saved, it also has a great impact on the user experience.

Nowadays, there are more and more mass-produced products based on i.MXRT, and there are more and more customer support about OTA security upgrade. When early i.MXRT models (such as i.MXRT1050/1020/1015) do FlexSPI NOR Flash-based OTA upgrades, one of the biggest pain points is that it is inconvenient to switch App versions, so later i.MXRT models (such as i.MXRT1064/1060/1010) add FlexSPI's Remap feature. Today, let's take a look at how this Remap feature is used for secure OTA.

1. Pain points in OTA Design 1.1 OTA General Design

Before talking about the inconvenience of App version switching, let's give you a brief introduction to the general routines of dealing with App version in the process of OTA upgrade design. The following is a typical OTA design NOR Flash content distribution, the front is generally L2 OTA Boot, responsible for updating or starting App;, followed by the main App area, that is, the real product function of App; and then Temp area, which is generally used as a temporary buffer for App updates; finally, User Data area, which stores some fixed picture resources (if there is a GUI), or puts some key system data saved dynamically.

The design of the Temp area is a key. If there is no Temp area, the main App area (App 1) can only be covered in place when the OTA is upgraded. In the event of an accident (such as a power outage) during the upgrade process, there will be no complete App available in the system, which will cause the product to become bricks. With the Temp area as the cache, the upgrade process will be much more reliable. As shown in the following figure, the new version of App (App 2) will first be placed in the Temp area. Only after the integrity verification of App 2 is passed will it be moved from the Temp area to the main App area, and then the Temp area will be erased after the move is completed. Under this design, even if an accident occurs when App 2 is downloaded to the Temp area or App 2 is moved to App 1, there is a full App in the system for recovery.

The typical design for dealing with App versions described above is not particularly common in practical applications, because there is only one up-to-date App in the system, which does not support version rollback. Sometimes our new version of App is unstable due to some reasons (for example, the new feature has bug). We want to be able to fall back to the previous stable version of App, and the system needs to keep two different versions of App, so we have the following improved OTA design NOR Flash content distribution, adding a secondary App area (App 1) after the main App area (App 2).

At this time, the upgrade process is a little more complicated. As shown in the following figure, there is one more step in the process of moving the primary App area (App 2) to the secondary App area (App 1), which is also the key to version rollback. However, everything comes at a price. The price of version rollback is to increase the time for OTA upgrades and to divide the App area of Flash into three segments, resulting in a reduction in the maximum length of App by 1 App.

1.2 App version switches pain points

Earlier, I introduced two methods for managing the App version in the OTA upgrade design. Note that the App here refers to the App that is executed in place (XIP) in the FlexSPI NOR Flash, and the code link in the internal SRAM of the chip or the App of the extended RAM is not discussed (there is no pain point for version switching in the App upgrade of this Non-XIP attribute). Now let's talk about the pain points of XIP App version switching:

In the figure above, you will find that the new version of App will eventually be moved to the main App area (the first App location immediately after the L2 OTA Boot). Why would you do that? This involves the knowledge of App links in MCU, because MCU is different from MPU in that it does not have MMU components and does not support virtual memory, so App is generally a fixed address link, and App code body binary data can be executed normally only if it is placed in the linked location, and copying App to a non-linked location cannot be run. Although there are different versions of App in OTA upgrades, these App all have a common link address, that is, they are all linked in the main App area.

For example, in the following figure, a Flash of 8MB is used in the OTA system. In i.MXRT, the system mapping starting address is 0x60000000 L2 OTA Boot and User Data respectively occupies 1MB, and the remaining 6MB is divided into three segments. Then App x 0x60100000 2and1 needs to link to release the interrupt vector table starting from the 0x60100000 address.

You may say that we can also design App with different link addresses, so that there is no need to move the new version of App to the main App area. Yes, in principle, this can be done, but in practice, it is necessary to manage the App of different link addresses, which makes the operation of the upper computer side of OTA upgrade more complex and error-prone (the current App to be upgraded must be different from the App link address of the last upgrade), so this method is not recommended.

So the biggest pain point is that App always has to move to the main App area, which not only increases the OTA upgrade time, but also reduces the life of Flash (the total number of erasure is certain).

Second, a detailed explanation of the FlexSPI Remap function 2.1 FlexSPI NOR system mapping address

We know that NOR Flash connected to FlexSPI can implement XIP, the main reason is that FlexSPI has corresponding system mapping space and NOR Flash itself can be accessed by Byte address, where the system mapping space is mainly used for AHB reading. CPU reads the App instruction code from the system mapping space, and the FlexSPI module will automatically convert the address data request from the AHB bus to the IPG command mode to obtain the corresponding instruction content in the NOR Flash. For more principles, see "debugging principles in Serial NOR Flash XIP".

The system mapping space allocated to FlexSPI in i.MXRT1060 is as follows, and a total of 496MB is allocated to the two FlexSPI.

The system mapping space allocated to FlexSPI in i.MXRT1010 is as follows, and a FlexSPI is assigned 504MB.

2.2 FlexSPI Remap function design

The Remap design in i.MXRT is actually at the system architecture level. An address redirection at the AHB bus level is not implemented in the FlexSPI module, which is why the Remap-related control is in the IOMUXC_GPR register (Remap takes effect immediately after setting, but these registers are not non-volatile, ordinary soft reset will be set). Here are the Remap control registers (for models with two FlexSPI, Remap control works at the same time):

Remap function corresponds to control register i.MXRT106xi.MXRT1010ADDR_STARTIOMUXC_GPR_GPR30IOMUXC_GPR_GPR27ADDR_ENDIOMUXC_GPR_GPR31IOMUXC_GPR_GPR28ADDR_OFFSETIOMUXC_GPR_GPR32IOMUXC_GPR_GPR29

Remap design is actually very simple, that is, AHB access in which the address (addr) falls in [ADDR_START, ADDR_END], which actually accesses the data at the location of addr + ADDR_OFFSET. (note that ADDR_START, ADDR_END, and ADDR_OFFSET are all 4KB-aligned)

For example, depending on the size of the ADDR_OFFSET, there are three situations: the first is ADDR_OFFSET = ADDR_END-ADDR_START, as shown in the following figure. This is also the most commonly used case in OTA. ADDR_START can be set to the starting address of the primary App area, and ADDR_END can be set to the starting address of the secondary App area.

The second is ADDR_OFFSET > ADDR_END-ADDR_START, as shown in the following figure:

The third is ADDR_OFFSET.

< ADDR_END - ADDR_START,如下图所示。不过这种情况在实际应用中并不推荐。

2.3 the influence of Remap on erasing and writing Flash

After enabling the Remap function, many people will be a little confused about calling the FlexSPI NOR driver function to erase and write Flash. In fact, there is no need to have this kind of doubt, erase and write Flash operation is the FlexSPI IPG command mode, belongs to the internal things of the FlexSPI module, completely not affected by the upper system Remap function, you can assume that the Remap function does not exist, the original how to do or how to do.

3. FlexSPI Remap to solve OTA pain points

With the Remap feature, let's go back to the OTA design, where we only need two App partitions. The new version of App (App 2) will first be placed in the back Temp area. After the update of App 2 is completed and the verification is passed, directly use the Remap feature to remap App 2 to the App 1 location, which does not add additional physical movement operations, but also retains the new and old App to achieve version rollback, and the whole OTA process has only one App erase and the shortest time to solve the pain point.

When the Remap function has been enabled, and then there is a new version of App (App 3) update requirements, it needs to be downloaded to the former Temp area, note that Flash erase and write operations are realized through IPG, so it is not disturbed by the Remap function, only need to pay attention to the absolute physical address offset, App download completion, cancel the Remap function, and so on.

The above is what is the pain point of App switching in OTA upgrade, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 260

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report