Les mises à jour de firmware Over-the-Air (OTA) sont une exigence incontournable pour les modules sans fil de production déployés sur le terrain. Un mécanisme de mise à jour mal conçu peut rendre les appareils inutilisables (brick), corrompre les données applicatives ou laisser des vulnérabilités de sécurité non corrigées. Cet article couvre la sélection du protocole de transport, la gestion du flash à double banque et les filets de sécurité de rollback, avec des exemples de code pour les plateformes nRF52 et ESP32.
Comparaison des protocoles de transport OTA
| Protocole | Débit | Surcharge | Portée | Recommandé pour |
|---|---|---|---|---|
| BLE GATT (MBU/DFU) | ~1-5 KB/s | 4 octets (en-tête ATT) | ~50 m | Dispositifs de terrain basse consommation |
| BLE L2CAP | ~10-30 KB/s | 4-6 octets | ~50 m | Mises à jour BLE plus rapides |
| Wi-Fi HTTP | ~200-800 KB/s | Pile TCP/IP | LAN/WAN | Module avec combo Wi-Fi |
| UART filaire | ~115-921 KB/s | Aucune (série) | Câblé uniquement | Gravure en ligne de production |
BLE GATT DFU reste le transport dominant pour les modules alimentés par batterie. Le DFU over BLE de Nordic utilise une caractéristique de point de contrôle (UUID 8EC90001-F315-4F60-9FB8-838830DAEA50) et une caractéristique de données (8EC90002-F315-4F60-9FB8-838830DAEA50). La négociation du MTU maximal (généralement 247 octets) limite le débit à ~2.5 KB/s avec des transferts à notification activée.
Architecture flash à double banque
L’approche à double banque stocke simultanément le firmware actif et la nouvelle image de firmware. Si la mise à jour échoue ou si la nouvelle image est corrompue, l’appareil démarre depuis la banque connue comme saine. Disposition mémoire sur nRF52840 (1 MB de flash) :
// nRF52840 dual-bank layout (SoftDevice S140)
// Bank 0 (active): 0x00026000 - 0x0005FFFF (214 KB app + 2 slots)
// Bank 1 (update): 0x00060000 - 0x0009FFFF (262 KB)
// SoftDevice: 0x00000000 - 0x00025FFF (152 KB)
// Bootloader: 0x000F8000 - 0x000FFFFF (32 KB)
// Minimum image size for dual-bank: (flash_total - SD - BL) / 2
// = (1048576 - 152000 - 32768) / 2 = 431904 bytes (~421 KB per bank)
// For typical BLE apps (~80-120 KB), dual-bank easily fits.Table des partitions OTA ESP32 :
# ESP32 partition table (single-bank OTA fallback)
# Name, Type, SubType, Offset, Size
nvs, data, nvs, 0x9000, 0x4000
otadata, data, ota, 0xd000, 0x2000
phy_init, data, phy, 0xf000, 0x1000
factory, app, factory, 0x10000, 1M
ota_0, app, ota_0, 0x110000, 1M
ota_1, app, ota_1, 0x210000, 1M
# otadata stores which partition (ota_0 or ota_1) is activeSignature et vérification de l’image firmware
Les images de firmware non signées sont trivialement altérables. Le DFU de Nordic exige des signatures ECDSA-P256 sur chaque image. Le bootloader vérifie la signature avant d’appliquer la mise à jour. Si la vérification échoue, l’appareil continue d’exécuter le firmware existant.
| Mesure de sécurité | Implémentation | Surcharge |
|---|---|---|
| Signature d’image (ECDSA-P256) | La clé privée signe le .zip ; le bootloader vérifie la clé publique | 64 octets de signature + 64 octets de clé publique dans le paquet init |
| Intégrité SHA-256 | Hachage du binaire firmware stocké dans le paquet init | 32 octets |
| Anti-rollback | Compteur de version monotone en flash ; le bootloader rejette la rétrogradation | 4 octets (champ de version) |
| CRC de fragment | CRC par fragment lors du transfert (CCITT 16 bits) | 2 octets par fragment |
Stratégie de rollback et de récupération
Même avec la signature d’image, des défaillances à l’exécution peuvent survenir (par exemple, le nouveau firmware plante au démarrage). Un mécanisme de récupération en trois étapes garantit la survivabilité de l’appareil :
- Validation au démarrage : Le bootloader vérifie le CRC de l’app à chaque démarrage. S’il est corrompu, il revient à la banque précédente.
- Vérification de santé de l’application : Dans les 30 secondes suivant le démarrage, l’app écrit un drapeau « health OK » sur une page flash spécifique. Si le drapeau est absent au démarrage suivant (l’app a planté avant l’écriture), le bootloader revient en arrière.
- Repli du watchdog : Le watchdog matériel indépendant (WDT) réinitialise le MCU si l’app reste bloquée plus de 8 secondes. Trois réinitialisations WDT consécutives déclenchent le rollback du bootloader.
// nRF52: Health check implementation
#define HEALTH_ADDR 0x000FE000 // Dedicated flash page for health flag
#define HEALTH_MAGIC 0xDEADBEEF
void app_health_check(void) {{
uint32_t val = 0xDEADBEEF;
sd_flash_write((uint32_t*)&val, HEALTH_ADDR, 1);
}}
// Bootloader check (in DFU bootloader):
// if (flash_read(HEALTH_ADDR) != HEALTH_MAGIC) {{ revert_bank(); }}Techniques d’optimisation de la bande passante
Via BLE GATT, le transfert d’une image firmware de 120 KB à 2.5 KB/s prend environ 48 secondes. Stratégies d’optimisation :
| Technique | Accélération | Compromis |
|---|---|---|
| Mises à jour delta (diff binaire) | 3-10x | Nécessite un calcul de diff côté serveur ; l’image de base doit correspondre |
| L2CAP CoC au lieu de GATT | 4-8x | Nécessite la négociation des paramètres de connexion ; moins compatible |
| Compression (LZMA/LZ4) | 2-3x | Coût CPU pour la décompression ; ~20 KB de surcharge de pile |
| MTU 247 + 6 notifications simultanées | 2x contre MTU 23 | Mémoire pour 6x tampons de notification (6 x 247 = ~1.5 KB) |
Exemple de mise à jour delta : Pour un firmware de 120 KB dont 8 KB changent entre les versions, un correctif binaire (algorithme bsdiff) produit un fichier delta d’environ 12 KB. Le temps de transfert passe de 48 secondes à ~5 secondes, soit une amélioration de près de 10x.
Pipeline OTA de production
- CI/CD compile le binaire firmware (.hex/.bin)
- Le serveur de signature applique la signature ECDSA-P256 → produit un .zip signé
- Le générateur de delta crée un patch incrémental par rapport à la version précédente
- Le serveur OTA héberge le manifeste firmware (version, taille, CRC, URL)
- L’appareil vérifie le manifeste, télécharge le delta ou l’image complète, vérifie et applique
- L’appareil redémarre sur le nouveau firmware ; la vérification de santé confirme le succès
Budget énergétique pendant l’OTA
Les mises à jour OTA sont énergivores. Une balise BLE alimentée par CR2477 avec un courant moyen de 10 μA passe à ~15 mA pendant la réception BLE pour le transfert de firmware. Calcul du budget pour une mise à jour de 120 KB :
# OTA power budget
IMAGE_SIZE = 120000 # bytes
THROUGHPUT = 2500 # bytes/sec (BLE GATT)
TRANSFER_TIME = IMAGE_SIZE / THROUGHPUT # = 48 seconds
RX_CURRENT = 15e-3 # 15 mA during RX
VOLTAGE = 3.0 # CR2477 nominal
CHARGE_CONSUMED = RX_CURRENT * TRANSFER_TIME / 3600 # = 0.0002 Ah = 200 μAh
# CR2477 capacity: 1000 mAh
# OTA consumes 0.02% of total battery per update
# With monthly updates: 0.24% annual OTA budget (negligible)Pour une OTA fiable, assurez-vous que l’appareil dispose de >20 % de batterie restante avant de lancer une mise à jour. L’appel sd_ble_gap_data_length_update() de la pile BLE avec MTU=247 et PHY=2M peut augmenter le débit à ~10 KB/s, réduisant le temps de transfert à ~12 secondes.
L’ingénierie firmware OTA est une fonctionnalité de fiabilité critique pour tout déploiement de production de module Bluetooth. La combinaison d’une architecture à double banque, de la signature ECDSA et du rollback par vérification de santé garantit que les appareils restent sécurisés et fonctionnels à travers des centaines de cycles de mise à jour. Notre équipe d’ingénierie propose la revue d’architecture OTA et la mise en place de l’infrastructure de signature pour les projets de module Bluetooth — contactez-nous pour une consultation technique.
