Mise à jour OTA bloquée sur les prototypes M10

1 Contexte & portée

Deux pannes de la chaîne OTA ont été observées au bring-up des prototypes M10 (modem u-blox SARA-R422M10S).

Ce document les 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 que se produisent les deux pannes. (La trace « Starting PDP » n'apparaît qu'en build verbeux APP_VERBOSE.)
5. Connexion au serveur & comparaison de checksum Téléchargement du checksum de référence pour cet IMEI, comparaison avec le firmware déjà flashé, mise à jour si différence.

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 Les deux symptômes observés

Deux pannes distinctes, deux codes d'erreur différents — mais exactement la même zone de code, juste après Starting PDP.

Le symptôme B (« operation not allowed », carte neuve) s'explique très probablement par un provisioning de première fois du modem : au tout premier allumage, le module doit initialiser la SIM/eSIM, faire sa première sélection d'opérateur et son premier attachement réseau. Tant que ce n'est pas terminé, une commande de données est refusée. Le deuxième démarrage réussit parce que le premier a amorcé ce provisioning — pas parce que la coupure d'alimentation aurait « nettoyé » quoi que ce soit. Le manuel AT définit d'ailleurs le code 3 comme « the MT is in a state which does not allow performing the entered command » (p. 48) — soit exactement « pas prêt pour cette commande ».

4 La racine commune

Dans les deux cas, le bootloader engage la phase de données alors que la pile réseau du modem n'est pas encore totalement prête — sans mécanisme robuste d'attente ou de nouvel essai à cet endroit.

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 ».

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.

① Remplacer l'activation forcée par une vérification d'IP priorité haute

Au lieu de AT+CGACT=1,1 (la commande qui échoue), interroger AT+CGPADDR en boucle jusqu'à obtenir une adresse IP valide (≠ 0.0.0.0), avec un délai généreux. C'est une lecture non destructive, conforme au LTE-M, et valable quelle que soit la cause. → Le meilleur correctif unique si on ne devait en faire qu'un.

// AVANT (à retirer) :
// AT+CGACT=1,1   -> "+CME ERROR: ..." si l'attachement n'est pas prêt

// APRÈS : attendre que le réseau ait attribué une IP (le contexte s'active seul en Cat-M1)
do {
    SARA_R422_Execute_Cmd(SARA_R422, "AT+CGPADDR=1\r\n");
    // lire "+CGPADDR: 1,<ip>"  -> succès si ip != 0.0.0.0
} while (ip_invalide && !timeout);

② Ajouter un nouvel essai de la phase de données, indépendant de FwIsConsistent priorité haute

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. C'est l'automatisation du power-off manuel — la mesure la plus importante pour le terrain (sondes montées).

③ 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.

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

Pour le symptôme B, démarrer en mode « déconnecté » puis déclencher l'enregistrement de façon explicite évite que le bootloader ne tire des commandes de données pendant que le modem fait encore son provisioning de première fois.

⑤ Renforcer le power-on — seulement si les tests le prouvent dernier recours

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 : comme le bootloader fait déjà un power-off complet au nouvel essai (§5), ce renforcement n'apporterait, au mieux, qu'un gain de temps au premier démarrage — et rien du tout si la cause réelle est ailleurs (radio, couverture, provisioning). À ne coder que si l'instrumentation prouve que le premier démarrage incomplet est bien en cause.

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, 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 (symptôme B) pour confirmer la piste provisioning.
• Décider, table en main, quels correctifs figer.

10 Niveaux de confiance

11 Carte du code (repères)