Follow+Star publicnumber, don’t miss the wonderful content
Source | Big Orange Crazy Embedded
Embedded development with IAP/OTA functionality has become a standard feature for most products. This year, let’s discuss and compare several IAP and OTA solutions!
📖 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 us with a more flexible and practical firmware update solution.
🔍 Technical Comparison
| Technology Type | ISP | IAP |
| Programming Method | Via professional debugger/downloader | Programming other partitions in 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 much more complex than a simple “two partition” setup. 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 basic and important 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 Bootloader communication protocol stack, with all programming operations implemented in the Bootloader, and the APP program is basically not involved in programming operations.
✅ Advantages
- • 🛡️ High Reliability: Can update even if there is no APP program or if the APP program is abnormal
- • 🔧 Strong Independence: Bootloader is completely independent and does not rely on APP status
❌ Disadvantages
- • 📦 Large Space Occupation: Bootloader is relatively complex, occupying a large amount of Flash space
- • 🔄 Complex Development: Requires maintaining 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 is still 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 flag
┌─────────────────┬─────────────────┬─────────────────┐
│ Bootloader │ APP1 │ APP2 │
│ Flash │ Flash │ Flash │
└─────────────────┴─────────────────┴─────────────────┘🎯 Best Practice: This is the safest and most reliable solution, but requires double Flash space!
🎯 Solution 2: APP Program Integrated Communication Protocol Stack
📋 Solution Features
The following solution integrates the APP communication protocol stack, with programming operations involved in both the Bootloader and APP program, and at least three areas need to be divided.
✅ 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 can easily 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, the Bootloader is only 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 Notes
🔧 Compilation and Linking Issues
Solution 3 and Solution 5 require separate compilation and linking of the APP due to different program running addresses, which greatly reduces applicability.
📡 Special Considerations for OTA Upgrades
OTA upgrades use wireless methods, 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 safety 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. Choosing the right solution requires comprehensive consideration of:
- • 🎯 Product Positioning: Consumer vs. Industrial
- • 💰 Cost Budget: Flash capacity vs. functional requirements
- • 🛡️ Safety 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!
———— END ————
● Column “Embedded Tools”
● Column “Embedded Development”
● Column “Keil Tutorials”
● Selected Tutorials from the Embedded Column
Follow the public accountReply “Join Group” to join the technical exchange group according to the rules, reply “1024” to see more content.
Click “Read the original text” to see more shares.