Mise à jour OTA bloquée sur les prototypes M10

1 Contexte & portée

La mise à jour à distance (OTA) échoue par intermittence sur les prototypes M10 (modem u-blox SARA-R422M10S) : le bootloader n'arrive pas toujours à joindre le webservice — que ce soit pour mettre à jour une sonde en service ou pour charger le firmware sur une carte neuve.

Ce document le décrit, propose un diagnostic appuyé sur la lecture du code et la documentation u-blox, distingue ce qui est vérifié de ce qui reste hypothèse, et liste les mesures et les tests à mener.

2 Le mécanisme OTA, étape par étape

À chaque démarrage, le bootloader exécute toujours la même séquence avant de passer la main à l'application.

1. Allumage du modem Mise sous tension et séquence de power-on.
2. Initialisation & attente d'enregistrement réseau Le modem doit être enregistré sur le réseau avant d'aller plus loin.
3. Lecture de l'IMEI Identifiant unique utilisé pour interroger le serveur.
4. Ouverture du contexte de données — « Starting PDP » C'est ici qu'échoue la connexion. (La trace « Starting PDP » n'apparaît qu'en build verbeux APP_VERBOSE.)
5. Connexion au serveur & comparaison de checksum Le bootloader compare le checksum du serveur au firmware flashé et, si une mise à jour est en attente, la télécharge. S'il ne peut pas se connecter (étape 4), la mise à jour échoue.

La séquence est lisible telle quelle dans la boucle principale du bootloader :

// 1. Power on SARA_R422
ret = SARA_R422_Power_On(&appdata->SARA_R422);
// 2. Initialize SARA_R422  (inclut l'attente d'enregistrement réseau)
ret = SARA_R422_Init(&appdata->SARA_R422);
// 3. Read and store IMEI
ret = SARA_R422_Get_IMEI(&appdata->SARA_R422, appdata->IMEI, ...);
debug_print("[DEBUG]Starting PDP...\r\n");
// 4. SARA R422 PDP activate  <-- POINT DE PANNE
ret = SARA_R422_PDP_Connect(&appdata->SARA_R422, APN);
// 5. Enable HTTP, puis GET du checksum, comparaison, upgrade...

L'ouverture du contexte (étape 4) repose sur ces deux commandes :

// Configure PDP Context
sprintf(buf, "AT+CGDCONT=1,\"IP\",\"%s\"\r\n", Apn);   // APN = "tsiot"
ret = SARA_R422_Execute_Cmd(SARA_R422, buf);
...
// Enable PDP Context
ret = SARA_R422_Execute_Cmd(SARA_R422, "AT+CGACT=1,1\r\n");   // <-- commande qui échoue

3 Le symptôme et les deux opérations touchées

La défaillance est toujours la même — l'ouverture de la connexion de données échoue juste après Starting PDP, et le bootloader ne peut plus joindre le webservice. Mais elle frappe dans deux opérations OTA bien réelles : la mise à jour d'une sonde en service, et le premier chargement du firmware sur une carte neuve.

...rebooting to bootloader to get the new firmware
NVM Firmware checksum                    : c4c2…e2dd0   // firmware actuel
Configuration message Firmware checksum  : 5c9c…91e42   // nouvelle cible reçue par l'app
...
[DEBUG]Starting PDP...
[ERROR]CME ERROR Received : +CME ERROR: no network service   // <-- la connexion échoue
[ERROR]Can not connect to TCP
[DEBUG]Jumping on App...                                // repart sur l'ancien firmware -> boucle

Les deux opérations touchées, avec deux codes d'erreur distincts mais au même endroit du code :

Les deux opérations échouent donc pour la même raison : le modem accroche en LTE-M et y voit CGACT refusé. (Sur une carte neuve, l'attachement de première fois — init SIM/eSIM, première sélection d'opérateur — peut s'ajouter ; le manuel AT décrit le code 3 comme « the MT is in a state which does not allow performing the entered command », p. 48. Mais cette piste « provisioning » reste secondaire face à la corrélation RAT.)

4 La racine commune

Dans tous les cas, le bootloader force AT+CGACT=1,1 — l'activation manuelle du contexte de données. Or, selon la techno sur laquelle le modem accroche, cette commande est soit nécessaire (2G), soit refusée (LTE-M, où le contexte est déjà monté).

Le levier choisi pour ouvrir la connexion est AT+CGACT=1,1, une commande standard (3GPP TS 27.007) d'activation explicite du contexte PDP, héritée du modèle GPRS où le contexte devait être activé à la main. Or :

Autrement dit, le code force une étape que le réseau fait déjà de lui-même, et l'émet au moment le plus fragile. Les deux codes d'erreur (« no network service » et « operation not allowed ») ne sont que deux façons, pour le modem, de dire « je ne suis pas prêt pour ça maintenant ».

Niveau de preuve : le mécanisme (CGACT refusé en LTE-M) est confirmé par la corrélation RAT de terrain (forte, non absolue). Ce qui reste à préciser : pourquoi un démarrage donné accroche en LTE-M plutôt qu'en 2G, et une éventuelle composante serveur (test curl §9). La piste « alimentation / rail batterie » est, elle, largement supplantée.

5 Une fausse piste, écartée en toute transparence

Une première intuition — « le redémarrage aimant rallume le modem trop vite, il faut forcer un cycle d'alimentation plus propre » — ne résiste pas à la lecture du code.

Le bootloader force déjà un power-off complet à chaque échec. En fin de boucle, il coupe proprement le modem puis met la carte en veille profonde 5 minutes, alimentation modem coupée :

while (1)
{
  ret = Application_Loop(&appdata);
  Modem_Reset(&appdata);                      // coupe proprement le modem (voir ci-dessous)
  // If an error occured, sleep to retry
  if (ret < 0 && appdata.FwIsConsistent != 1)
      Sleep(SLEEP_DURATION_SEC);             // 300 s = 5 min, alim modem coupée
  else
      Jump_To_App(&appdata);                 // démarre l'application
}

SARA_R422_Execute_Cmd(SARA_R422, "AT+CPWROFF\r\n");      // extinction logicielle
...
ret = SARA_R422_Wait_Powered(SARA_R422_AT_SUPPLY_OFF_DELAY, GPIO_PIN_RESET); // attend que VINT retombe — modem réellement OFF (2000 ms)
...
HAL_GPIO_WritePin(SARA_R422_POWER_SUPPLY, GPIO_PIN_RESET);  // coupe l'alimentation

Le firmware refait donc déjà, tout seul, l'essentiel de ce qu'un power-off manuel accomplit : coupure de l'alimentation modem + rail coupé 5 minutes + redémarrage à froid. « Forcer un cycle propre » est donc largement redondant — ce n'est pas là qu'est la solution. Cette correction est assumée : mieux vaut écarter une fausse piste que de coder un faux remède.

6 Le vrai trou : un nouvel essai conditionné au mauvais critère

Si le bootloader sait refaire un cycle propre, pourquoi faut-il quand même une intervention humaine ?

Parce que ce nouvel essai automatique ne se déclenche que si le firmware interne est jugé « non cohérent ». La condition exacte (revoir l'extrait section 5) est :

Le correctif en découle directement : il faut un nouvel essai de la phase de données, indépendant de la cohérence du firmware — c'est l'automatisation du geste manuel « power-off + redémarrage » constaté sur le terrain.

7 Ce que dit la documentation u-blox

Plusieurs recommandations du fabricant convergent vers le même constat : la séquence actuelle est conçue « à l'ancienne » et mérite d'être alignée sur les bonnes pratiques Cat-M1.

8 Points à améliorer (par ordre de priorité)

Ce sont des spécifications. Elles vont du correctif direct du symptôme aux durcissements de fond.

① Ne plus faire de « operation not allowed » un échec — valider sur l'IP priorité haute — correctif racine

Le problème n'est pas AT+CGACT=1,1 en soi (elle reste nécessaire en 2G), mais le fait d'en faire un échec quand elle est refusée. En LTE-M, « operation not allowed » veut juste dire « contexte déjà monté ». Le correctif : émettre CGACT, ne pas bloquer sur sa réponse, et valider sur l'obtention d'une IP (AT+CGPADDR). Marche en 2G comme en LTE-M — et donc après le retrait de la 2G. → Le correctif de fond, ciblé sur la cause prouvée (corrélation RAT).

// CGACT reste nécessaire en 2G — mais on NE bloque PLUS sur sa réponse :
SARA_R422_Execute_Cmd(SARA_R422, "AT+CGACT=1,1\r\n");
//  "OK"                                -> 2G : contexte activé
//  "+CME ERROR: operation not allowed" -> LTE-M : déjà actif   => les DEUX sont OK

// La vraie validation : a-t-on une IP ?
do {
    SARA_R422_Execute_Cmd(SARA_R422, "AT+CGPADDR=1\r\n");
    // "+CGPADDR: 1,<ip>"  -> succès si ip != 0.0.0.0
} while (ip_invalide && !timeout);
if (ip_invalide) return -1;   // là seulement, vrai échec

② Nouvel essai de la phase de données, indépendant de FwIsConsistent robustesse

Autour de l'appel à SARA_R422_PDP_Connect (application.c, lignes 462-470), prévoir 2 à 3 tentatives qui rejouent un cycle radio propre avant d'abandonner : AT+CFUN=0 puis AT+CFUN=1 force un nouvel attachement sans redémarrage complet. Avec le correctif ①, la connexion réussit dès la 1ʳᵉ tentative quelle que soit la techno : ce retry n'est donc plus le correctif central, mais un bon filet contre les vrais creux réseau (pas de couverture à l'instant T) — et il évite de dépendre d'un redémarrage externe.

③ Attendre la disponibilité réelle de la donnée avant de l'utiliser durcissement

L'attente actuelle valide l'enregistrement réseau, mais rien ne garantit ensuite que le service paquet est prêt avant d'émettre la première commande de données. Vérifier explicitement l'attachement paquet (AT+CGATT? = 1) — et idéalement passer l'enregistrement en notification URC (AT+CEREG=2) — comble cet écart. ⚠️ Si on passe en URC, il faut tokeniser le champ <stat> : le strncmp actuel sur « +CEREG: 0,1 » casse avec l'URC « +CEREG: 1,1 ».

④ Reprendre la main sur la sélection d'opérateur au démarrage cas carte neuve

Reprendre la main sur la séquence d'enregistrement (démarrer en mode « déconnecté » puis déclencher l'enregistrement explicitement) permet de maîtriser le choix de techno et le timing au démarrage — utile notamment au premier allumage d'une carte neuve. Secondaire une fois ① en place.

⑤ Renforcer le power-on probablement supplanté

Au power-on, la décharge avant réalimentation repose sur de simples temporisations aveugles (1 s avant réalimentation, 1 s après), sans jamais vérifier que le modem est réellement éteint :

HAL_GPIO_WritePin(SARA_R422_PWR_ON, GPIO_PIN_RESET);        // (L399)
HAL_GPIO_WritePin(SARA_R422_POWER_SUPPLY, GPIO_PIN_RESET);  // coupe l'alim (L400)
// Wait capacitors to discharge
HAL_Delay(SARA_R422_SUPPLY_ON_DELAY);                       // 1000 ms AVEUGLE, pas de contrôle VINT (L403)
HAL_GPIO_WritePin(SARA_R422_POWER_SUPPLY, GPIO_PIN_SET);    // réalimente (L406)
HAL_Delay(SARA_R422_SUPPLY_ON_DELAY);                       // encore 1000 ms aveugle (L407)

On pourrait attendre le passage à l'état bas de VINT (la primitive existe déjà) et allonger la marge de décharge — la règle u-blox « couper VCC seulement après VINT bas » figure au System Integration Manual, p. 32. Mais la corrélation RAT supplante très probablement cette piste : ce qui décide de l'échec, c'est la techno d'accroche (LTE-M), pas la propreté du cycle d'alim — un power-cycle plus propre ne ferait, au mieux, que biaiser le choix de techno. À ne considérer que si ① ne suffisait pas.

9 Tests à mener (avant de figer un correctif)

L'analyse est statique. Une instrumentation légère tranchera entre les causes possibles et confirmera (ou non) chaque hypothèse.

Instrumentation à ajouter

Faire enregistrer par le bootloader, juste avant l'ouverture du contexte de données et en numérotant le passage (1^er démarrage / nouvel essai n°…) :

Table de décision

Checklist

• Activer AT+CMEE=2 et recompiler en mode verbeux.
• Instrumenter le log (code CME, commande fautive, RAT (2G/LTE-M), CEREG/CGATT/CSQ/CGPADDR, n° de passage).
• Série de ≥10 redémarrages aimant — noter persistance ou non au 2^e passage.
• Idem sur carte neuve : vérifier qu'elle accroche aussi en LTE-M.
• Décider, table en main, quels correctifs figer.

10 Niveaux de confiance

11 Carte du code (repères)