Comment fonctionnent les bootloarders

Comment fonctionnent les Bootloaders

Introduction

Initialement, la manière de charger le code programme dans les microcontrôleurs (MCUs) se faisait grâce à un programmateur – un outil hardware spécialement développé pour cette tâche.

Lorsqu’une mise à jour du firmware était nécessaire, habituellement il fallait renvoyer le produit chez le fournisseur ou attendre qu’un technicien muni du programmateur viennent sur site effectuer l’opération. De nos jours, il est courant de mettre à jour (update) le firmware sans utiliser de programmateur – à la condition que le microcontrôleur dispose d’un programme appelé ‘bootloader’. Ceci est rendu possible grâce aux améliorations apportées au type de mémoire programme utilisée dans les microcontrôleurs ainsi qu’aux évolutions de l’architecture interne ; un bootloader suppose que le microcontrôleur soit en mesure d’écrire dans sa propre mémoire programme, donc de se programmer lui-même.

EPROM, EEPROM & Flash

Au début de l’ère des microcontrôleurs, des EPROM (Erasable Programmable Read-Only Memory) étaient utilisées ; ces composants avaient une fenêtre visible sur la partie supérieure qui servait à effacer le contenu en les soumettant à une lumière UV.

Après Les EPROM sont apparus les EEPROM (Electrically Erasable Programmable Read-Only Memory), effaçable de manière électronique avec un programmateur. Bien qu’une EEPROM pouvait se programmer elle-même et que quelques microcontrôleurs disposaient de cette fonctionnalité, ils ont été rapidement remplacés par de la mémoire FLASH considérablement moins chère. Les mémoires FLASH initiales nécessitaient des hautes tensions pour les programmer/effacer avec un programmateur externe. Cependant les dispositifs capables de fournir ces tensions ont, par la suite, été intégrés directement dans les composants. La mémoire FLASH est toujours celle utilisée dans les microcontrôleurs actuels et avec cette fonctionnalité d’auto-programmation interne au MCU, les bootloaders sont devenus possibles.

Bootloaders

Le principe d’un bootloader est que le microcontrôleur reçoit les données du nouveau programme via une méthode de communication – qui peut être USB, WIFI, Ethernet, UART, SPI, CAN, SD-card, etc – pour les écrire dans la mémoire programme du composant. En même temps, le bootloader peut écrire sur lui-même, ce qui suppose de diviser la mémoire programme en plusieurs zones distinctes.

Si vous avez lu notre post sur les mémoires FLASH, alors vous savez que ce type de mémoire est divisé en secteurs. Un (ou plusieurs) de ces secteurs sont réservés au programme bootloader et les autres dédiés au programme de l’application (le code sur lequel on se connecte – le boot). Une autre approche, si on dispose de suffisamment de mémoire Flash, est d’inclure le code bootloader dans le code de l’application, d’avoir deux ou plus de zones de FLASH de tailles identiques réservées à la mémoire programme et de commuter entre celles-ci à chaque fois qu’un nouveau programme est mise à jour.

La méthode 1 s’adapte naturellement à tout type de code programme et ainsi peut charger toute application écrite pour un microcontrôleur spécifique à partir du moment où le code n’utilise pas le secteur de la mémoire FASH dans lequel réside le programme bootloader. Le code de l’application peut fonctionner sans bootloader (le code est chargé directement avec un programmateur) ou avec un bootloader.

La méthode 2 nécessite qu’un code bootloader soit ajouté dans l’application à chaque mise à jour. Si ce n’est pas le cas, il ne sera pas possible de charger le code ultérieurement sauf à disposer d’un programmateur externe.

Entrer en mode bootloader

Lors de l’utilisation de méthodes où le bootloader est séparé du programme application (méthode 1), il faut décider à quel moment le transfert du contrôle est passé au bootloader. Ceci peut être fait depuis le programme application lorsqu’une condition intervient (par exemple une commande reçue via un port de communication ou l’appui sur un bouton) ou une autre technique qui lance brièvement le bootloader (pendant quelques secondes) au démarrage afin qu’il vérifie qu’une nouvelle version du firmware soit disponible en téléchargement (tentative de se connecter à un ordinateur en attente via USB par exemple) avant de transférer le contrôle au programme application. L’avantage de commencer par lancer le bootloader au démarrage avant le programme application, c’est que lorsqu’un problème ou un bug intervient dans l’application, il est possible de charger un autre programme dans le micro. Afin de s’assurer que le bootloader se lance en premier, ceci implique de modifier le vecteur de reset dans le code. Le vecteur de reset est l’adresse mémoire à laquelle le MCU se connecte après un reset.

Cette adaptation du programme (modification du vecteur reset) peut être faite avant que le code application soit passé au bootloader, par exemple par un programme sur ordinateur qui se connecte au bootloader via USB, ce qui réduit la complexité et la taille du bootloader. Certains microcontrôleurs comme le ATMEDA328P utilisé dans la carte populaire Arduino Uno, possèdent un fusible programmable qui permet de modifier le vecteur reset, sans rien devoir modifier dans la mémoire FLASH / programmation application.

Étude de cas : Bootloading Arduino depuis une carte SD

Un projet exemple Proteus est fourni dans le lien ci-dessous; c’est une simulation d’un bootloader pour Arduino Uno (ATMEGA328P), qui charge un nouveau firmware depuis une carte SD.

Une copie de Proteus est necessaire pour ouvrir le ficher .pdsprj

Ce bootloader, appelé avr_boot (https://github.com/zevero/avr_boot) recherche un fichier firmware de nom FIRMWARE.BIN sur une carte SD pour le charger sur le MCU. Il fau connecter la carte SD avec le nouveau programme, allumer ou resetter le MCU afin que la nouvelle application soit mise à jour. Deux images différentes de cartes SD sont incluses, avec deux programmes. Le contenu de la carte SD peut être change en éditant les propriétés du composant SD card du schéma :

Les réglages du fusible firmware et bootloader sont spécifiés de la même manière (clic droit sur le microcontrôleur AVR puis éditer le composant)

Si vous souhaitez voir la mémoire FLASH du MCU pour vérifier le process du bootloading:

Puis un lancement de la simulation en pause permet d’observer que la mémoire à l’adresse 0x0000 est vide:

Lancez brièvement la simulation et mettez à nouveau en pause pour constater que la mémoire flash a été remplie avec le programme bootloader.

Traduction française