Comment déboguer les appareils IoT basés sur Zephyr : pratiques éprouvées de surveillance à distance

Le projet open source Zephyr de la Linux Foundation est devenu la pierre angulaire d'innombrables solutions IoT. Avec un système d'exploitation temps réel (RTOS) léger, évolutif, conçu pour les appareils à ressources contraintes, Zephyr prend en charge un large spectre d'architectures — ARC, Arm, Intel, Nios, RISC-V, SPARC, Tensilica — et plus de 250 cartes. Aujourd'hui, le projet compte 1 000 contributeurs et 50 000 commits, élargissant continuellement sa portée multi-architecture.

Le développement pour Zephyr exige une attention à la fiabilité. Les problèmes qui apparaissent en laboratoire disparaissent souvent seulement lorsque les appareils sont mis à l'échelle, ou lorsque les piles réseau évoluent. Une stratégie robuste de surveillance et de débogage à distance est essentielle pour détecter, diagnostiquer et résoudre les problèmes avant qu'ils ne se traduisent en temps d'arrêt coûteux.

Considérons notre travail avec des traceurs GPS pour la surveillance d'animaux d'élevage. Chaque collier devait fonctionner sans heurts à travers plusieurs réseaux cellulaires, pays et zones d'itinérance. Une décharge de puissance inattendue due à une mauvaise configuration se serait traduite par une perte économique significative. Nous avions besoin non seulement de signaler le problème, mais de comprendre sa cause racine et de déployer un correctif — d'où la nécessité d'une observabilité à distance en temps réel.

Nous avons combiné Zephyr avec Memfault, une plateforme d'observabilité d'appareils basée sur le cloud, pour construire une pile de surveillance qui couvre les mises à jour firmware, les redémarrages, les watchdogs, les fautes, les assertions et les métriques de connectivité.

Configuration d'une plateforme d'observabilité

Memfault permet aux développeurs de surveiller, déboguer et déployer des modifications firmware à distance, permettant :

• Des déploiements en production gracieux qui évitent les gels
• Une surveillance continue de la santé des flottes d'appareils
• Des correctifs sans temps d'arrêt livrés avant que les utilisateurs ne remarquent un problème

L'intégration du SDK Memfault dans Zephyr est simple : ajoutez le module à votre manifeste west.yml et activez-le dans prj.conf.

# west.yml [ ... ] - name: memfault-firmware-sdk url: https://github.com/memfault/memfault-firmware-sdk path: modules/memfault-firmware-sdk revision: master # prj.conf CONFIG_MEMFAULT=y CONFIG_MEMFAULT_HTTP_ENABLE=y

1️⃣ Se concentrer sur les redémarrages

L'augmentation des taux de réinitialisation est souvent le premier signe d'un problème plus profond — dégradation matérielle, bogues firmware ou anomalies réseau. En distinguant les réinitialisations matérielles et logicielles, vous pouvez identifier si une faute est généralisée ou isolée à un sous-ensemble d'appareils.

Enregistrer la raison avant un redémarrage

void fw_update_finish(void) { // … memfault_reboot_tracking_mark_reset_imminent(kMfltRebootReason_FirmwareUpdate, ...); sys_reboot(0); }

Zephyr préserve une région définie par l'utilisateur à travers les réinitialisations ; Memfault s'y connecte pour capturer le contexte du redémarrage. Après un redémarrage, enregistrez un gestionnaire d'initialisation pour lire la raison du redémarrage matériel et l'envoyer au cloud.

static int record_reboot_reason(void) { // 1. Lire le registre de raison de redémarrage matériel (voir datasheet MCU) // 2. Capturer la raison du redémarrage logiciel depuis la RAM noinit // 3. Envoyer les données au serveur pour agrégation } SYS_INIT(record_reboot_reason, APPLICATION, CONFIG_KERNEL_INIT_PRIORITY_DEFAULT);

Exemple : un défaut d'alimentation peut se manifester par des milliers de redémarrages en peu de temps. La Figure 1 montre une flotte où 99 % des 12 000 redémarrages par jour sont attribués à seulement dix appareils — probablement un problème mécanique ou de batterie. Les mises à jour firmware peuvent atténuer de tels problèmes, mais la surveillance à distance permet de les détecter et de les traiter avant qu'ils ne s'aggravent.

• 12K redémarrages d'appareils par jour – trop nombreux
• 99% des redémarrages provenant de 10 appareils
• Défaut mécanique causant des réinitialisations constantes

2️⃣ Exploiter les watchdogs

Les watchdogs sont votre dernière ligne de défense contre les blocages — qu'ils soient causés par des piles réseau bloquées, des boucles infinies, des interblocages ou de la corruption mémoire. Zephyr expose une API watchdog unifiée qui abstrait les différences matérielles.

void start_watchdog(void) { struct device *s_wdt = device_get_binding(DT_LABEL(DT_INST(0, nordic_nrf_watchdog))); struct wdt_timeout_cfg wdt_config = { .flags = WDT_FLAG_RESET_SOC, .window.min = 0U, .window.max = WDT_MAX_WINDOW, }; s_wdt_channel_id = wdt_install_timeout(s_wdt, &wdt_config); const uint8_t options = WDT_OPT_PAUSE_HALTED_BY_DBG; wdt_setup(s_wdt, options); } void feed_watchdog(void) { wdt_feed(s_wdt, s_wdt_channel_id); }

Pour le Nordic nRF9160, le flux de travail typique est :

1. Configurer l'arbre de périphériques pour le watchdog.
2. Définir les paramètres via l'API.
3. Installer le watchdog.
4. L'alimenter périodiquement ; un alimentation manquée déclenche un redémarrage et un gestionnaire de faute Zephyr.

Memfault capture l'état pré-redémarrage, vous permettant de remonter au chemin de code fautif. Exemple : un pilote SPI qui se bloque après 16 mois de déploiement est révélé par une faute initiée par le watchdog. La Figure 2 illustre la chronologie et la dégradation, tandis que la Figure 3 montre le dump de registres du gestionnaire de faute.

3️⃣ Gérer les fautes et assertions

Lorsqu'une assertion ou une faute se déclenche, le gestionnaire de faute de Zephyr capture l'état du CPU. Memfault s'intègre parfaitement à ce flux, persistant les registres, le contexte du noyau et un instantané de toutes les tâches actives vers le cloud.

void network_send(void) { const size_t packet_size = 1500; void *buffer = z_malloc(packet_size); // Vérification NULL manquante mène à une faute memcpy(buffer, 0x0, packet_size); } bool memfault_coredump_save(const sMemfaultCoredumpSaveInfo *save_info) { // Stocker l'état des registres, contexte noyau & tâches, instantané .bss/.data sélectionné } void sys_arch_reboot(int type) { // … }

Diagnostics clés incluent :

1. Le registre d'état de faute Cortex-M indique la cause.
2. Memfault restaure la ligne de code exacte et les états des tâches environnantes.
3. La structure _kernel révèle l'état de l'ordonnanceur et, pour les piles connectées, les paramètres Bluetooth ou LTE.

4️⃣ Suivre les métriques au niveau de l'appareil

Les métriques donnent une vue quantifiable de la santé de la flotte. Les valeurs couramment surveillées incluent la charge CPU, les métriques de connectivité et les données thermiques. Le SDK Memfault vous permet de déclarer et de rapporter des métriques avec un code minimal.

1. Définir une métrique

MEMFAULT_METRICS_KEY_DEFINE( LteDisconnect, kMemfaultMetricType_Unsigned)

2. Mettre à jour dans le code

void lte_disconnect(void) { memfault_metrics_heartbeat_add( MEMFAULT_METRICS_KEY(LteDisconnect), 1); // … }

Le backend cloud de Memfault agrège les métriques par appareil et version firmware, fournissant une UI web pour comparer les flottes et déclencher des alertes. Cas d'usage typiques :

• Connectivité NB-IoT/LTE-M : surveiller les états d'alimentation du modem pour évaluer l'impact sur la batterie.
• Événements de tours cellulaires et timing PSM : identifier les zones de qualité de signal qui drainent l'énergie.
• Télémétrie de grande flotte : repérer les valeurs aberrantes et les pics de données inattendus.

• Taille de données UDP par intervalle d'envoi.
• Pic de données après redémarrage.
• Gros paquets indiquent des traces embarquées ou diagnostics.
• Utiliser les métriques pour contrôler l'utilisation des données et le coût.

Conclusion

En intégrant Zephyr avec Memfault, les développeurs gagnent une pile d'observabilité puissante de bout en bout. Concentrez-vous sur quatre piliers — redémarrages, watchdogs, fautes/assertions et métriques de connectivité — et vous transformerez une flotte d'appareils de boîtes noires opaques en systèmes transparents et gérables. Pour des insights plus profonds, regardez la présentation enregistrée du Zephyr Developer Summit 2021.