Mettre à niveau ARM sur les ondes

Nous allons créer une carte ARM avec un modem GSM embarqué.
Nous voulons pouvoir mettre à jour le firmware ARM par voie hertzienne.

Existe-t-il une bonne solution open source fiable pour cela?
Sinon, existe-t-il un système d'exploitation payant avec cette fonctionnalité?

wireless arm firmware hotips
la source

ARM est assez générique: il existe de nombreux fabricants qui intègrent des architectures ARM, et certains d'entre eux peuvent fournir cette fonctionnalité.

clabacchio

Une information plus spécifique sur la puce / famille ARM que vous prévoyez d'utiliser serait bien. De nombreux microcontrôleurs Cortex-M, sinon tous, prennent en charge l'écriture dans la mémoire flash à partir du code utilisateur. Il existe des exemples d'implémentations open source, comme le chargeur de démarrage Maple leaflabs.com/docs/bootloader.html , et je pense avoir vu une mise à niveau du micrologiciel sur une liaison radio prise en charge par certains quadcoptères.

Thorn

Nous n'avons pas choisi l'appareil ARM pour le moment;)

hotips

Le gros problème avec les mises à jour du firmware est de savoir comment forcer la puce en mode de mise à jour une fois qu'il y a un problème avec le firmware. Lorsque vous avez accès à la puce, vous pouvez la réinitialiser et forcer une broche de chargement haute, mais comment allez-vous le faire par liaison radio? La seule solution fiable que je peux imaginer est d'avoir une deuxième puce (non actualisable) qui gère la communication de base et peut mettre à jour la puce principale. Après avoir résolu ce problème, le démarrage réel peut être aussi simple que l'utilisation (par exemple) du chargeur de démarrage intégré à la puce (par exemple, les uc du LPC que je connais tous ont un chargeur de démarrage série).

Wouter van Ooijen

@Hernan Cela rendrait possible des modes de défaillance subtils, comme une puce (exécutant en quelque sorte le mauvais code) gardant l'autre réinitialisée. La seule solution vraiment fiable consiste à conserver les fonctions dans une puce si simple que vous n'aurez jamais besoin de la mettre à jour.

Wouter van Ooijen

Réponses:

Je ne connais pas de solutions prédéfinies mais je vais décrire comment je l'ai fait dans un projet. Ce n'est pas totalement «incassable» mais je ne suis pas conscient qu'il échoue sur des milliers de mises à niveau. Pour cette application, un taux de défaillance très faible serait toujours moins cher que d'avoir à accéder aux unités.

L'application principale a trois types de paquets supplémentaires ajoutés à son protocole de communication normal qui inclut la détection des erreurs et une stratégie de nouvelle tentative en haut:

Une commande begin firmware update efface une zone de mémoire réservée dans un flash SPI externe. Il renvoie une erreur si l'unité fonctionne à partir de sa batterie de secours ou si elle fonctionne à partir d'une alimentation externe mais que l'état de charge de la batterie est inférieur à 25%.
Une commande de bloc d'écriture accepte une adresse de décalage et des données qui sont écrites dans la mémoire Flash externe en petits morceaux. Le protocole de niveau supérieur s'occupe de la détection des erreurs et des retransmissions. Une fois chaque bloc écrit, il est relu et vérifié avant que la commande ne soit acquittée.
Une commande de fin de mise à jour du micrologiciel inclut la longueur du micrologiciel reçu avec un CRC32 de l'image entière pour une vérification plus approfondie. Si cela correspond au contenu de la mémoire flash externe et que les conditions d'alimentation sont toujours OK, la même longueur et CRC32 sont transférés dans une zone EEPROM avec un `` nombre magique '' pour indiquer qu'une mise à jour du firmware est en attente.
Une boucle dure est exécutée dans l'application principale pour forcer un redémarrage du chien de garde.
Le chargeur de démarrage (qui se trouve dans une zone protégée en écriture du Flash de l'ARM) voit le nombre magique dans l'EEPROM et vérifie une fois de plus le CRC32 de l'image. Si tout est OK, il transfère l'image du flash externe dans la zone de programme principale du flash de l'ARM.
Les informations de mise à niveau en attente sont effacées de l'EEPROM et une boucle dure force un autre redémarrage. Cette fois, le chargeur de démarrage démarre normalement l'application principale.

Bien que je n'aie jamais vu la phase de mise à jour échouer à tester de nouvelles versions de micrologiciel avant le déploiement, il est crucial d'utiliser cette méthode. Si une nouvelle version n'est pas capable de se connecter au réseau GSM et d'accepter les commandes de mise à jour futures, elle nécessitera une mise à jour du micrologiciel sur site.

PeterJ
la source

Utilisez-vous Linux ou un RTOS, ou du bare metal? Si vous utilisez Debian, vous pouvez prendre un instantané du système de fichiers actuel, faire une mise à niveau via "apt-get" puis conserver ou annuler les modifications selon que cela a fonctionné ou non.

fred basset
la source

Nous avons Linux et le bare metal selon l'application ;-)

hotips

Si vous avez Linux, vous pouvez exploiter une grande partie de cette infrastructure. La façon dont je gère les mises à jour sur mon projet actuel consiste à créer des fichiers .deb pour les applications personnalisées, puis à utiliser apt-get update pour mettre à jour le système. J'expérimente également avec btrfs. Ce système de fichiers vous permet de prendre des instantanés. Mon plan consiste donc à créer un instantané des répertoires souhaités, à essayer de le mettre à jour et, si cela n'a pas fonctionné, à rétablir l'instantané. Si vous êtes sur du métal nu, vous devrez probablement opter pour l'approche à double mémoire habituelle, une image pour le dernier code de travail et une autre pour le code fraîchement téléchargé.

fred basset