Comment nous avons résolu un problème de crash récurrent d’un système embarqué Android basé sur un processeur SoC RK3066

Une compagnie montréalaise qui distribue des systèmes autonomes est venue nous voir il y a 2 semaines suite à un problème urgent sur un système Android basé sur SoC RK3066. En effet ils ont pu observer que les appareils gelaient parfois durant leur séquence de démarrage, et que la seule solution était de débrancher/rebrancher l’appareil par un technicien dépêché sur placé. Les appareils étant installés sur de grande distances et devant souvent redémarrer, cette solution n’était pas une option.

Étude du problème

Spiria a tout d'abord mis en place un banc de test pour être capable de reproduire le problème. Constat, la panne est sévère :

  • Pas de possibilité d’accès à une console (adb shell) ou aux journaux d’événements Android (adb logcat)
  • La mémoire vidéo semble également corrompue (artefacts visuels à l’écran)

Afin d'obtenir plus d'informations, nous avons alors ouvert le boitier et nous avons recherché un accès direct à l'UART (Universal Asynchronous Receiver/Transmitter) du coeur.

Une fois repéré sur la carte, un chip FT232 nous a permis de convertir les signaux TTL (Transistor-Transistor Logic) de l'UART en signaux lisibles sur un port série (RS232) de PC.

On a pu alors observer que le cœur est lui-même gelé et qu'il n'y a pas de rapport d'erreurs.

Causes envisageables :

  • Bogue matériel (arbitrage de bus / contrôleur d'IRQ... ?)
  • Bogue logiciel de bas niveau (dead lock/concurrence sous une IT de hautes priorités, type FIQ ?)

Causes non envisageables :

  • Corruption mémoire, côté application

Vu la sévérité du problème, et le manque de disponibilité du code source du système, nous avons tenté de trouver et d'activer un « Watchdog » matériel. Un watchdog est un périphérique presque toujours présent dans les SoC (System-On-Chip), mais il est souvent désactivé en production.

 

Lorsque activé, Il permet une réinitialisation matérielle du système automatiquement si le logiciel ne donne plus de signe de vie au bout d'un certain temps.

Mise en place du Watchdog

Côté matériel :

  • Étude du SoC RK3066 de Rockchip (Dual Core ARM Cortex-A9)
  • Identification et configuration des blocs matériels CRU/PMU/WDT sur l'APB en vue d'activer l'IP « Watchdog »
  • Rétroingénierie + document retrouvé in extrémis sur Internet, car Rockchip était un peu réticent à fournir ce genre d'information

Côté logiciel :

  • Réalisation d'un pilote pour Android 4.1.1 (linux uname -r: 3.0.8)
  • Réalisation d'une application générique d’accès aux registres de l'APB depuis l'espace utilisateur
  • Réalisation d'un service système Java pour le keep-alive du Watchdog depuis Android

Livraison :

  • Réalisation d'une solution pour un Depack/Repack complet d'image ROM Android/RK pour l'application d'un correctif.

Notons qu'ici, nous n'avons pas eu besoin du code source d'Android ou de la recompilation du noyau.

À partir de la ROM fournie directement par notre client, nous avons pu fournir une nouvelle ROM contenant:

  • Le nouveau pilote
  • Un outil accessible à la console
  • Une configuration ajustée (init.rc) pour l'initialisation du système
  • Le nouveau service système Android pour le keep alive

Tests

Un banc de tests nous a permis de mesurer le résultat : Avant / Après.

Ces campagnes de tests réalisées sur plusieurs jours ont démontré que la nouvelle image ROM livrée permet de s'affranchir d'une personne pour relancer les afficheurs lorsqu'ils gèlent (le redémarrage automatique s'effectue en moins de 2 minutes).

Découvrez nos histoires
à succès.

Un projet de développement logiciel?
Contactez-nous!  

Cette entrée a été publiée dans IoT, M2M & systèmes embarqués
par Jan D’Orgeville.
Partager l’article