In-Depth Analysis of Embedded IAP/OTA Upgrade Technology: From Principles to Practice

πŸ”§ 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. 1. πŸ“¨ Send upgrade command β†’ MCU
  2. 2. πŸ”„ MCU reset/jump β†’ Enter Bootloader
  3. 3. πŸ—‘οΈ Bootloader erase current APP program
  4. 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. 1. πŸ“¨ Send upgrade command β†’ MCU
  2. 2. πŸ”„ MCU reset/jump β†’ Enter Bootloader
  3. 3. πŸ“₯ Receive new APP program β†’ Write to blank Flash
  4. 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. 1. πŸ“¨ Send upgrade command β†’ MCU
  2. 2. πŸ”„ MCU reset/jump β†’ Enter Bootloader
  3. 3. πŸ“₯ Receive new APP program β†’ Write to APP2
  4. 4. βœ… After successful verification β†’ Clear APP1 valid flag β†’ Set APP2 valid flag
  5. 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. 1. πŸ“¨ Send upgrade command β†’ MCU
  2. 2. πŸ“₯ APP starts receiving new program β†’ Write to blank Flash
  3. 3. βœ… After successful verification β†’ Reset/jump to Bootloader
  4. 4. πŸ—‘οΈ Bootloader erases current APP program
  5. 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. 1. πŸ“¨ Send upgrade command β†’ MCU
  2. 2. πŸ“₯ APP receives new program β†’ Write to APP2
  3. 3. βœ… After successful verification β†’ Clear APP1 valid flag β†’ Set APP2 valid flag
  4. 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. 1. πŸ›‘οΈ Safety First: Prioritize dual APP solutions (Solution 3/5)
  2. 2. πŸ“¦ Space Optimization: Balance security and cost based on product needs
  3. 3. πŸ”„ Fault Tolerance Design: Implement breakpoint resume and verification mechanisms
  4. 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!

Leave a Comment