π§ In-Depth Analysis of Embedded IAP/OTA Upgrade Technology: From Principles to Practice
π‘ Technical Knowledge Sharing | Click the blue text above to learn more practical skills in embedded programmingπ If you find this article helpful, feel free to like and follow
π Introduction
In the world of embedded development, IAP (In Application Programming) technology is one of the core skills that every engineer needs to master. Unlike traditional ISP (In System Programming), IAP technology provides a more flexible and practical firmware update solution.
π Technology Comparison
| Technology Type | ISP | IAP |
| Programming Method | Via specialized debuggers/downloaders | Programming other partitions within the application |
| Typical Tools | JTAG, SWD, etc. | Bootloader |
| Flexibility | Requires external tools | Can be updated remotely |
OTA (Over The Air Technology) is the wireless implementation of IAP technology, enabling remote firmware updates via wireless communication methods such as Bluetooth and WiFi, greatly enhancing product maintainability and user experience.
π In-Depth Analysis of IAP Technology Solutions
In actual product development, the implementation of IAP technology is far more complex than a simple “two partition” approach. We need to consider:
- β’ β What to do in case of upgrade failure?
- β’ β How to restore the factory version?
- β’ β How to ensure the reliability of the upgrade?
- β’ β How to optimize storage space usage?
π‘ Importance of Communication Protocol Stack
When developing IAP, the communication protocol stack (used for receiving firmware programs) is the most fundamental and crucial component. Let’s take a look at several mainstream implementation solutions:
π― Solution 1: Bootloader Integrated Communication Protocol Stack
π Solution Features
The following solution integrates the communication protocol stack into the Bootloader, with all programming operations implemented within the Bootloader, and the APP program is minimally involved in programming operations.
β Advantages
- β’ π‘οΈ High Reliability: Can update even if the APP program is absent or malfunctioning
- β’ π§ Strong Independence: Bootloader is completely independent and does not rely on APP status
β Disadvantages
- β’ π¦ Large Space Occupation: Bootloader is relatively complex, occupying a significant amount of Flash space
- β’ π Complex Development: Requires maintenance of two sets of communication protocols
π Solution 1: Direct Overwrite Update
Workflow:
- 1. π¨ Send upgrade command β MCU
- 2. π MCU reset/jump β Enter Bootloader
- 3. ποΈ Bootloader erase current APP program
- 4. π₯ Receive new APP program β Directly write to APP partition
βββββββββββββββββββ¬ββββββββββββββββββ
β Bootloader β APP β
β Flash β Flash β
βββββββββββββββββββ΄ββββββββββββββββββ
β οΈ Risk Warning: Power interruption during the upgrade may brick the device!
π Solution 2: Buffered Update
Workflow:
- 1. π¨ Send upgrade command β MCU
- 2. π MCU reset/jump β Enter Bootloader
- 3. π₯ Receive new APP program β Write to blank Flash
- 4. β After successful verification β Erase old APP β Write new APP
βββββββββββββββββββ¬ββββββββββββββββββ¬ββββββββββββββββββ
β Bootloader β APP β Blank Flash β
β Flash β Flash β β
βββββββββββββββββββ΄ββββββββββββββββββ΄ββββββββββββββββββ
β Advantages: The original program remains available in case of upgrade failure, providing higher security!
π Solution 3: Dual APP Alternating Update
Workflow:
- 1. π¨ Send upgrade command β MCU
- 2. π MCU reset/jump β Enter Bootloader
- 3. π₯ Receive new APP program β Write to APP2
- 4. β After successful verification β Clear APP1 valid flag β Set APP2 valid flag
- 5. π On next update β Erase APP1 β Write new program to APP1 β Switch flags
βββββββββββββββββββ¬ββββββββββββββββββ¬ββββββββββββββββββ
β Bootloader β APP1 β APP2 β
β Flash β Flash β Flash β
βββββββββββββββββββ΄ββββββββββββββββββ΄ββββββββββββββββββ
π― Best Practice: This is the safest and most reliable solution, but requires double the Flash space!
π― Solution 2: APP Program Integrated Communication Protocol Stack
π Solution Features
The following solution integrates the communication protocol stack into the APP, with programming operations involved in both the Bootloader and APP program, requiring at least three partition areas.
β Advantages
- β’ πΎ Space Saving: Bootloader program occupies less Flash space
- β’ π Development Efficiency: APP program iterates quickly with rich features
β Disadvantages
- β’ β οΈ High Dependency: Cannot perform updates without the APP program
- β’ π° Higher Cost: Requires larger Flash capacity
- β’ π Higher Risk: Rapid iteration of the APP program may introduce bugs, affecting update functionality
π Solution 4: APP Receives + Bootloader Writes
Workflow:
- 1. π¨ Send upgrade command β MCU
- 2. π₯ APP starts receiving new program β Write to blank Flash
- 3. β After successful verification β Reset/jump to Bootloader
- 4. ποΈ Bootloader erases current APP program
- 5. π Bootloader writes new program to APP partition
βββββββββββββββββββ¬ββββββββββββββββββ¬ββββββββββββββββββ
β Bootloader β APP β Blank Flash β
β Flash β Flash β β
βββββββββββββββββββ΄ββββββββββββββββββ΄ββββββββββββββββββ
π€ Why can’t we write directly in the APP? Just like you can’t “jump with both feet” at the same time, a program cannot modify itself while running!
π Solution 5: APP Fully Autonomous Update
Workflow:
- 1. π¨ Send upgrade command β MCU
- 2. π₯ APP receives new program β Write to APP2
- 3. β After successful verification β Clear APP1 valid flag β Set APP2 valid flag
- 4. π After reset β Bootloader selects APP to start based on the flag
βββββββββββββββββββ¬ββββββββββββββββββ¬ββββββββββββββββββ
β Bootloader β APP1 β APP2 β
β Flash β Flash β Flash β
βββββββββββββββββββ΄ββββββββββββββββββ΄ββββββββββββββββββ
π‘ Features: Only the APP is involved in programming operations, while the Bootloader is solely responsible for startup selection!
π Summary of Solutions Comparison
π― Solution Selection Recommendations
| Solution | Applicable Scenarios | Flash Requirement | Security | Development Complexity |
| Solution 1 | Simple Applications | Low | ββ | β |
| Solution 2 | General Products | Medium | βββ | ββ |
| Solution 3 | High Reliability Products | High | βββββ | βββ |
| Solution 4 | Cost-Sensitive Products | Medium | βββ | βββ |
| Solution 5 | High-End Products | High | ββββ | ββββ |
β οΈ Important Considerations
π§ Compilation and Linking Issues
Solution 3 and Solution 5 require separate compilation and linking of the APP due to different program run addresses, which significantly reduces applicability.
π‘ Special Considerations for OTA Upgrades
OTA upgrades use wireless methods, which compared to “direct wired upgrades”:
- β’ πΆ Higher Disconnection Risk: Unstable networks may lead to upgrade interruptions
- β’ π Higher Error Probability: Wireless transmission is more prone to data errors
- β’ β±οΈ Not Suitable for Real-Time Writing: It is not recommended for the MCU to write immediately after receiving each frame of data
π‘ Best Practice Recommendations
- 1. π‘οΈ Safety First: Prioritize dual APP solutions (Solution 3/5)
- 2. π¦ Space Optimization: Balance security and cost based on product needs
- 3. π Fault Tolerance Design: Implement breakpoint resume and verification mechanisms
- 4. π Status Monitoring: Add upgrade progress and status feedback
π Conclusion
IAP/OTA technology is an indispensable feature of modern embedded products, and choosing the right solution requires comprehensive consideration of:
- β’ π― Product Positioning: Consumer vs. Industrial
- β’ π° Cost Budget: Flash capacity vs. functional requirements
- β’ π‘οΈ Security Requirements: Reliability vs. development complexity
- β’ π± User Experience: Upgrade success rate vs. operational convenience
π¬ Interactive Topic: What IAP solutions have you used in your projects? What pitfalls have you encountered? Feel free to share your experiences in the comments!
π Related Recommendations
- β’ π More Technical Articles: Click the blue text above to follow
- β’ π‘ Recommended Practical Tools: Essential toolset for embedded development
- β’ π Advanced Courses: Practical training on IAP protocol stack development
If this article has been helpful to you, please like π + follow π + share π€
Your support is my motivation to continue sharing!