Reconfiguration d'un FPGA
Sommaire
Cahier des charges
Projet réalisé par Simon Malthieu.
Tuteurs : Alexandre Boé, Thomas Vantroy, Mickaël Coronado.
Suite à la réunion avec Mickaël Coronado, gérant de Inodesign, le cahier des charges suivant a été établi : Alexandre : Ce cahier des charges est beaucoup trop bref.
Description du projet
Le but du projet est de permettre une mise à jour aisé d'un FPGA. Il y a deux manières de programmer un FPGA. Soit directement via une liaison J-TAG. Dans ce cas-ci, le FPGA devra être reprogrammé à chaque mise sous tension. Il existe cependant une autre solution, qui consiste à associer une mémoire de type EEPROM au FPGA. Ainsi, il suffit d'écrire le bitstream dans la mémoire, et la mémoire va le charger dans le FPGA à chaque mise sous tension. Alexandre : Attention aux coquilles et aux phrases.
Les deux manières devront être développées.
L'interface devra aussi pouvoir vérifier l'intégrité des données, afin d'éviter un chargement de bitstream corrompu.
L'autre partie du projet consiste à gérer la partie récupération du bitstream par FTP, ou mieux par SFTP. L'ensemble devra donc être autonome, de la récupération du bitstream à programmation du FPGA.
Spécifications techniques
La plateforme choisie pour ce projet est la beaglebone black. C'est un micro-ordinateur miniature embarquant un processeur Texas Instrument, modèle Sitara XAM3359AZCZ100 Cortex A8 ARM cadencé à 1 GHz. Une exemplaire de cette plateforme est prêté par Mickaël Coronado pour les besoins du projet.
Un système d'exploitation est inclus de base dans la eMMC de la beaglebone. Il faudra savoir si cela suffit pour développer le programme, ou s'il faut installer un autre OS.
Le langage choisi est le C.
L'écriture dans l'EEPROM se fait via interface SPI, qu'il faudra configurer.
Étapes de la première partie : Ecriture dans l'EEPROM
- Prise en main de la Beaglebone black (OS, interface de développement, ...)
- Conception d'une carte de test avec une EEPROM et une interface SPI pour tester le programme. La création de la carte est effectué par Inodesign grâce à un schéma qu'il faudra dessiner, à la main ou grâce à un logiciel comme Altium.
- Lire les registres de l'EEPROM : Le début de l'EEPROM est constitué de registres contenant des informations diverses comme sa taille, sa date de fabrication ou son constructeur. Le but est de pouvoir lire ces registres depuis la beaglebone.
- Écrire dans l'EEPROM via SPI
Prise en main de la BBB
Liens hypertextes destinés à la prise en main
- Site internet de la distribution linux Angstrom
- Tutoriel de prise en main de la BBB (eng)
- Flashage d'une carte SD en ligne de commande
- Dernières versions de Angstrom pour BBB
Mise à jour de la distribution
La BBB possède une mémoire interne : une eMMC de 2Go, ce qui est amplement suffisant pour le projet. D'office, une distribution linux spécialement créée pour la programmation embarquée est installée sur la eMMC : Angstrom distribution. Afin d'avoir le dernier noyau et les dernières optimisations, une mise à jour est nécessaire.
Les étapes pour mettre à jour la BBB sont :
- Décompresser l'image téléchargé sur le site de la beagleboard
- Flasher une carte SD (> 4Go) avec l'image. Ligne de commande utilisée :
sudo dd bs=4M if=~/Documents/Projet/BBB-eMMC-flasher-2013.09.04.img of=/dev/sdc
bs indique le nombre d'octets maximum à transmettre en même temps.
- Débrancher la BBB et insérer la carte SD à l'interieur.
- Rester appuyé sur le bouton BOOT (le plus prêt de la carte SD) et alimenter la BBB. Le flashage devrait commencer. Cela peut durer jusqu'à 45 minutes. Une fois terminé, les LEDs à droite du port Ethernet restent allumées. Il suffit alors de débrancher la BBB puis de la rebrancher EN AYANT RETIRÉ LA CARTE SD ! Sinon le flashage recommence.
Accéder à la BBB
Une interface réseau est simulé lorsqu'on branche la BBB par USB sur un ordinateur. Sous Ubuntu 13.10, aucun driver spécifique n'est nécessaire, l'interface est immédiatement reconnue. Une interface web est disponible avec une page de présentation à l'adresse 192.168.7.2 . L'IDE cloud 9 en web-application est aussi préinstallé et disponible sur le port 3000. Malgré de riches fonctionnalités, cloud 9 ne semble pas convenir au développement en langage C : Pas de debugeur ni de compilateur disponible d'après le site internet.
La meilleure solution reste SSH. On y accède par la commande ssh root@beaglebone.local . Aucun mot de passe par défaut. Gcc et Vim sont déjà installés.
Il est aussi possible de s'y connecter via minicom directement (9600 bauds, sans contrôle de flux sur /dev/ttyACM0)
Interface SPI
Liens à propos de SPI
- Tutoriel en anglais sur SPI, EEPROM et BBB
- Page wikipedia sur le SPI
- Doc du noyau sur SPI
- Tutoriel sur les pins sous linux
Configuration sur la BBB
Afin de pouvoir écrire et lire avec read() et write() en C directement, il faut activer le(s) périphérique(s) spidev*. Une série de commandes permet de les créer. Tout est expliqué ici.
Plusieurs fichiers de test sont disponible sur internet : ici et là.
Problème du lundi 17/02 : spidev1.0 est effectivement créé, mais il disparaît à chaque redémarrage. 19/02 : résolu, le fichier uDev.txt était mal modifié (toutes les commandes doivent être sur la même ligne).
Réalisation de la carte de test
L'EEPROM utilisé est une M25P80 de chez Micron. Il faut les empreintes de ces composants au format Altium pour créer le PCB. Elles sont disponibles sur le site Altium après création d'un compte. PCB créé, mais la carte ne peut pas être réalisée à l'école pour l'instant, car les machines permettant de créer les circuits sont hors-services.
En attendant, Mr Thierry Flamen possède des circuits pré-imprimé spécialement pour des petits composants CMS comme cette EEPROM. Les trous sont percés et le composant est soudé dessus.
Lecture de l'EEPROM
Liens utiles
* Datasheet de la M25P80
Branchement de la mémoire avec des fils directement sur la beaglebone black. Les trous destinés à l'interface SPI sont disponibles ici.
tentative de lecture directement avec les fonctions fournies par spidev_fdx.c, mais rien n'est lu. D'après la datasheet, il faut envoyer des commandes avant de pouvoir lire. Par exemple, pour lire le nom du fabriquant il faut envoyer la commande READ DESCRIPTION dont le code de commande est 69h.
En s'inspirant des fonctions de spidev_fdx.c, écriture d'un programme de lecture de la description de l'EEPROM. Mais le 12/03, aucune valeurs reçues. Il faudrait vérifier les signaux SPI générés par la BBB, ainsi que les signaux envoyés par l'EEPROM grâce à un oscilloscope.
L'analyseur logique confirme que le programme fonctionne. Les trames correspondent au comportement voulu. Vérification des pistes de cuivres de la carte, recherche de court-circuit. Rien de concluant. Un ampèremètre est branché en série de l'alimentation pour vérifier que l'EEPROM fonctionne et n'a pas été endommagé lors de la soudure des broches. Observation d'une augmentation de la consommation lors d'une tentative d'écriture.
Finalement, après avoir lu en détail la datasheet, l'EEPROM était en DEEP DOWN STATE et n'acceptait aucune commande autre que celle de réveil. Après l'envoi de celle-ci, les autres commandes de lecture fonctionnent et renvoient bien des données le 19/03.
La commande READ DESCRIPTION renvoie bien les données concernant le fabricant et la taille de la mémoire. Données vérifiées par la datasheet.
26/03 : Écriture d'une fonction de lecture. Afin de lire des données, il faut envoyer la commande READ DATA puis une addresse sur 3 octets. Tant que l'EEPROM est sélectionnée (Chip select à 0), l'EEPROM renvoie les données contenues à partir de l'adresse transmise. Pour l'instant, l'EEPROM est vide et ne transmet que des 1, car les informations écrites sont des 0. Par exemple la commande BULK ERASE met tous les bits de l'EEPROM à 1.
30-31/03 : Différentes fonctions écrites pour lire le registre de description, lire et écrire dans le registre d'état et lire et écrire dans la mémoire. La fonction d'écriture ne semblait ne pas fonctionner, puisque la lecture de la mémoire ne renvoyait que des 1. Or après analyse à l'analyseur logique, le problème venait de la fonction de lecture, qui envoyait mal la commande de lecture.
