Very High Speed Integrated Circuit Hardware Description Language/Programmer in Situ et déboguer
Nous avons l'intention d'examiner dans ce chapitre toutes les techniques permettant de programmer et déboguer in Situ. Tous les projets réalisés dans les chapitres précédents nécessitaient une compilation complète de tout le projet chaque fois qu'un programme C était changé. Cela était parfois très long (10 min sur de vieux PCs) et donc assez contraignant. Il est ainsi intéressant de passer en revue diverses techniques pour simplement envoyer un programme dans la RAM du FPGA sans recompiler l’ensemble du projet. Dans l'univers des Microcontrôleurs existants, on appelle cela la programmation in-situ (In-System Programming : ISP dans la suite de ce document). Chez Atmel ou chez MicroChip par exemple l'ISP (In-System Programming) se décline en deux façons différentes : le SPI (Serial Peripheral Interface) et le JTAG. Cet ensemble est aussi parfois appelé (en) In Circuit Serial Programming (ICSP). Les fichiers envoyés seront au format HEX (Intel) ou binaire.
Après avoir examiné ces problèmes de programmation, nous nous tournerons vers les problèmes de débogage certainement encore plus complexes.
Introduction (pour Xilinx)
modifierMême si nous avons déjà eu l’occasion d'évoquer ce sujet dans une annexe du chapitre sur l'AVR ATMega8, nous pensons qu'une deuxième explication ne sera pas de trop. Regardez attentivement la figure ci-dessous :
Elle montre clairement que la chaîne de compilation matérielle (à gauche) n'a aucun lien avec la chaîne de compilation logicielle (à droite). Autrement dit, l'ISE de Xilinx est incapable de mettre un programme logiciel compilé en mémoire matérielle. Comment peut-on modifier ce fait ?
La méthode généralement utilisée consiste à proposer un utilitaire capable de transformer le résultat d'une compilation en un fichier VHDL. Les débutants en VHDL ont un peu de mal à se faire à cette idée : quel est le rapport entre VHDL et mémoire ? Pour eux, nous allons proposer plus loin dans ce chapitre une section qui examine la réalisation de mémoire en VHDL. Voici en image un exemple encore lié à l'ATMega8.
Qu'a-t-on ajouté ? On a ajouté un programme externe "make_mem" capable de transformer un fichier HEX en fichier VHDL qui sera inséré dans le projet (pour l'exemple avec le fichier mem_content.vhd). Cette façon de faire est à mon avis la plus simple et tout projet devrait la proposer au moins pour les débutants. Mais elle est cependant loin d’être un must. En effet tout changement dans le programme C nécessite de réaliser la compilation des programmes C ce qui prend quelques secondes puis de transformer le fichier HEX en fichier VHD ce qui ne prend aussi que quelques secondes et enfin de compiler le projet VHDL en entier ce qui peut prendre un certain temps (10 - 15 min sur un vieux PC). Lancer ISE pour compiler un projet important est toujours consommateur de temps. Il nous faut donc explorer d'autres solutions et c’est bien l'objectif de ce chapitre.
Présentation générale des techniques de base
modifierPour ne pas tout réinventer et rester dans l'univers de ce qui se fait couramment avec les micro controleurs modernes, nous voyons diverses façons de procéder pour envoyer un programme compilé dans notre FPGA :
- utiliser le protocole ISP existant (sur certains processeurs),
- utiliser la RS232,
- utiliser l'interface JTAG.
La mise en œuvre d'un de ces protocoles consiste donc à ajouter un module capable de dialoguer avec un PC pour remplir les mémoires. Cela consiste à intervenir directement dans le FPGA : votre fichier BIT est téléchargé dans votre FPGA et vous voulez vous servir d'une liaison quelconque pour y mettre un programme. Mais un petit coup d’œil à la figure précédente montre qu’il y a un autre point d'entrée : le fichier d’extension ".bit". C'est ce que nous allons examiner maintenant.
Avant de commencer, un petit détour par data2mem
modifier"data2mem" est un utilitaire fourni par Xilinx pour résoudre les problèmes de compilation. Il est capable de prendre des valeurs hexadécimales et les mettre dans la BRAM du FPGA. En clair, il est capable de prendre un fichier matériel compilé (d'extension ".bit") et d'y insérer des valeurs qui finiront dans la BRAM lors du téléchargement du fichier ".bit". Cette solution réduit elle aussi le temps de compilation matérielle : vous compilez votre logiciel et data2mem vous insère le résultat dans le fichier ".bit" que vous n'êtes donc pas obligé de refaire en entier. Pourtant, même si nous avons l'intention d'essayer cette solution, nous préférons aller de l'avant et explorer d'autres solutions. La raison est simple :
- "data2mem" est un outil en ligne de commande, donc délicat à maîtriser
- "data2mem" est un outil Xilinx, donc propriétaire dont on ne connaît pas le code source. Le forum de Xilinx indique même que certaines versions de l'ISE ont un data2mem comportant des bogues (surtout pour les spartan6 !!!)
- "data2mem" nécessite une connaissance des BRAM approfondie ou en tout cas connaître la façon dont votre BRAM est utilisée par votre outil de synthèse.
Pour ceux qui ne sont pas convaincu par la première raison indiquée, voici le résultat affiché quand on le lance :
[smoutou@localhost lin]$ ./data2mem
Release 11.1i - Data2MEM L.33, build 1.5.8 Jul 23, 2008
Copyright (c) 1995-2011 Xilinx, Inc. All rights reserved.
Data2MEM <-bm FILENAME [.bmm]> |
<<[-bm FILENAME [.bmm]]>
<-bd FILENAME [<.elf>|<.mem>] [<[<boot [ADDRESS]>] tag TagName <TagName>...>]>...
<-o <u|v|h|m> FILENAME [.ucf|.v|.vhd|.mem]>
<-p PARTNAME>
-i>> |
<<-bd FILENAME [.elf]> -d [e|r]> [<-o m FILENAME [.mem]>]>> |
<<-bm FILENAME [.bmm]>
<-bd FILENAME [<.elf>|<.mem>] [<[<boot [ADDRESS]>] tag TagName <TagName>...>]>...
<-bt FILENAME [.bit]> <-o b FILENAME [.bit]>> |
<<-bm FILENAME [.bmm]> <-bt FILENAME [.bit]> -d>> |
<-bx [FILEPATH]> |
<-mf <p PNAME PTYPE PID <a SNAME MTYPE ASTART BWIDTH <s BSIZE DWIDTH IBASE>...>...>...>> |
<<-pp FILENAME [.bmm]> <-o p FILENAME [.bmm]>> |
<-f FILENAME [.opt]> |
<-w [on|off] > |
<-q [s|e|w|i]> |
<-intstyle silent|ise|xflow> |
<-log [FILENAME [.dmr]]> |
<-u> |
<-h [ <option [< option>...]> | support ]>
-h option_list | all | sup[port]
Print help text for command line options. If only a '-h' is given, then
only the option summary is output. If the '-h' is followed by a space
separated list of option names (without the dash), help is output for
the listed options. For example, '-h bm bd i' gives help on the 'bm',
'bd', and 'i' options. Use '-h all' for help on all options. Lastly,
use '-h support' to list the devices Data2MEM supports. The
keyword 'support' can be abbreviated up to 'sup'.
De quoi refroidir quelques ardeurs non ?
L'environnement Microblaze XPS (Xilinx Platform Studio) utilise data2mem, comme vous pouvez le constater dans le chapitre sur le MicroBlaze de ce livre.
On le trouve aussi dans un autre projet openMSP430, sous la forme :
data2mem -bm ../memory.bmm -bd $1.elf -bt openMSP430_fpga.bit -o b $1.bit
qui montre que l’on peut charger des fichiers au format elf (ce qui était vrai aussi pour le MicroBlaze). Cette commande nous fait aussi deviner la présence d'un fichier spécial d'extension .bmm, qui est un fichier pour décrire où et comment la ROM est implanté dans les BRAM (Bloc RAM). Et c’est là que réside le problème. Nous avons utilisé cette technique pour deux processeurs et la réalisation du fichier .bmm n'a jamais été une partie de plaisir. Nous avons même échoué sur un troisième projet. Il nous manque certainement de l'expérience pour comprendre quelques subtilités mais préférons passer du temps à utiliser les SOCs plutôt que de devenir spécialiste de data2mem ! La réalisation automatique de ce fichier .bmm est décrite un peu plus loin dans ce chapitre.
Il existe aussi un outil sous DOS/windows pour faire cela comme expliqué dans la section suivante pour le cas particulier du picoBlaze mais nous ne l'avons jamais utilisé.
Utiliser la RS232 pour programmer
modifierNous avons déjà eu l’occasion d'examiner la RS232 dans un chapitre précédent. Nous allons donc utiliser les résultats de ce chapitre pour réaliser une programmation à travers la RS232. L'avantage de cette technique est qu’il n’est pas difficile de trouver pour n’importe quel système d'exploitation (Windows, (GNU) Linux, Mac OS X ou autres) un logiciel capable d'envoyer et/ou recevoir des fichiers par une liaison série qui passe éventuellement par l’USB.
Utiliser un cœur Série asynchrone pour programmer
modifierIl existe deux projets chez OpenCores qui ont des fonctions élémentaires de programmation par la liaison série. Ces cœurs peuvent être utilisés pour remplacer un bootloader. Leur mise en œuvre est un peu plus générale que ce que l’on vient de faire mais cela nécessite un peu de réflexion. Il faudra en effet partager la mémoire entre le processeur et le cœur série. Pour les trouver chez Opencores :
- Dans les projets chercher "Communication contoller" puis "UART to Bus" de Litochevski Moti et Muller Steve
- Dans les projets chercher "(en) System controller" puis "RS232 System Controller" de John Clayton.
Le premier projet est disponible en Verilog et en VHDL et relativement compact. Le deuxième projet est en verilog et a servi pour développer un processeur.
Développons un peu l’utilisation pratique de ces deux cœurs à partir de leur documentation (nous ne les avons pas mis en œuvre).
Projet UART to Bus
modifierCe projet est destiné à réaliser une communication série permettant de remplir ou de lire une mémoire. Il comporte deux modes distincs :
- un mode texte où commandes et données sont envoyés en caractères ASCII donc facile à utiliser avec un hyperterminal
- un mode binaire où commandes et données sont envoyées et reçues en binaire.
Les deux seules commandes sont :
- 'W' ou 'w' pour écriture avec la syntaxe : "W 0D 16FFRC" où RC désigne le retour Chariot réalisé par LF ou CR. Cette commande écrit 0x0D en adresse 0x16FF.
- 'R' ou 'r' pour lecture avec la syntaxe "R 1A2FRC" où RC désigne le retour Chariot réalisé par LF ou CR. Cette commande retourne le contenu d'une mémoire en adresse 0x1A2F.
Projet RS232 System Controller
modifierEn plus des commandes du projet précédent (write et read) une nouvelle commande 'i' pour initialisation qui est un reset est présente. Ce projet nécessite un bus Whishbone qui peut être partagé entre un processeur et ce cœur ce qui en fait un outil de choix pour développer un processeur en VHDL.
Ce qui reste à faire dans ce chapitre est la réalisation d'un chargeur de mémoire universel par rs232 (sans bootloader) d'un fichier HEX et tout cela de manière indépendante du fondeur...
Utiliser l'interface Série synchrone pour programmer directement
modifierL'interface In System Programming (ISP) peut se traduire par "programmation à même le circuit". Dans ce chapitre nous garderons la terminologie anglo-saxonne.
Ce type de programmation des Microcontrôleurs est assez généralisée. On la trouve bien entendu dans les AVR de chez Atmel et dans les microcontôleurs PIC.
Ce système est tiré du protocole Serial Peripheral Interface : certains constructeurs respectent le nom des broches de ce protocole, d'autres non.
Utiliser le protocole In-System Programming (ISP) existant est probablement très attractif. Cela permettrait par exemple d’utiliser un environnement de développement comme AVRStudio de compiler avec cet environnement et de télécharger directement dans le FPGA, tout cela de manière transparente. Mais le protocole utilisé ne dépend-t-il pas des fabricants et voir des familles chez un même fabricant ? La réponse est évidemment affirmative. Cela lui enlève beaucoup d’intérêt du coup : vous allez passer beaucoup de temps à développer un module ISP pour un AVR (par exemple), mais ce même module sera incapable de dialoguer avec MPLAB et un PIC !
Nous présentons quand même un cœur qui permet de ne pas partir de rien !
Un cœur chez OpenCore
modifier- spi master slave de Doin Jonny est probablement un cœur à examiner pour continuer ce chapitre. Sa description est traduite maintenant.
Doin Jonny, auteur de ce cœur écrit : Ce projet est parti du besoin d’avoir une simple interface SPI écrite en VHDL pour utiliser un interfaçage FPGA/circuit générique.
Le cœur ainsi réalisé génère un circuit petit et efficace capable d'opérer avec des horloges lentes jusqu'à des horloges de 50 MHz.
Ce projet comporte deux cœurs indépendants : SPI_MASTER et SPI_SLAVE le maître et l'esclave.
Les deux cœurs sont écrits en VHDL avec une architecture pipeline et des domaines d'horloge bien séparés pour l'horloge du bus SPI et celle de l'interface parallèle.
La conception ciblait originellement les Spartan-6 de chez Xilinx mais est écrit en code synthétisable indépandant de la téchnologie. Les cirsuits préservent les ressources d'horloge du FPGA en utilisant directement l'horloge rapide pour toutes les bascules avec une entrée "clock enables" (CE) pour les registres.
Le maître et l'esclave ont été vérifiés en hardware en utilisant la carte "Digilent Atlys board (Spartan-6 @100 MHz)" avec une horloge SPI de 500 kHz à 50 MHz, avec aucun déphasage et des opérations robustes.
Si vous trouvez ce cœur utile, faites le moi savoir: jdoin@opencores.org
Performances
- cœur VHDL, complètement synchrone, conçu avec une architecture RTL pipelinée classique, avec une horloge globale grande vitesse
- Interface SPI très petite et efficace
- paramétrisable avec des generics : (N, CPOL, CPHA, PREFETCH, SPI_2X_CLK_DIV)
- modes SPI (CPOL, CPHA): supporte les modes 0,1,2,3
- largeur des mots (N): de 8 bits à le limite de synthèse (accepte n’importe quelle largeur de mots)
- Lookahead input data request (PREFETCH): pipelined data request for back-to-back data transmission
- SPI diviseur par 2x de l'horloge rapide système
- Très économique : pas de FIFO, juste un buffer de sortie parallèle pour les données reçues
- Lecture et écriture parallèles similaires à de la RAM
- domaines d'horloges indépendants pour le bus série et la lecture et l'écriture du bus parallèle avec des pipelines de transferts
- Peut être utilisé pour contrôler des cirsuits généraux SPI (maîtres) ou comme interface à des unités centrales (esclaves)
- Indépendant du fondeur, entièrement conçu en LUT/FF, n'utilise aucune structure spécifique à Xilinx, IOBs ou registres à décalage
- Synthetise jusqu'à +210 MHz dans une Spartan-6 (lowest grade), en utilisant seulement de la logique CLB
- Vérifiée en silicium avec une horloge à 100 MHz, utilisant des fréquences SPI de 500 kHz jusqu'à 50 MHz dans une Spartan-6 XC6SLX45-2
- Très petite: 41 slices pour 2 ports (une interface maître + une interface esclave) avec 32 bits de largeur de mots
Signalons qu'un autre chapitre de ce livre utilise ce cœur SPI (partie esclave de ce cœur) dans un domaine complètement différent (Communication entre processeur et FPGA).
Avant de passer au vif du sujet, il nous faut examiner là où l’on a l'intention de mettre le programme, j’ai nommé les mémoires.
Mémoire et FPGA
modifierVous pouvez lire la section RAM et FPGA du wikibook Conception et VHDL qui vous montre un exemple d'utilisation de RAM en VHDL.
Tous les FPGA modernes proposent deux sortes de RAM : une mémoire bloc (appelée BRAM dans la suite de ce document) et une mémoire distribuée (appelée DRAM dans la suite de ce document).
Si vous voulez écrire dans ces mémoires en VHDL, il vous faut respecter un certain nombre de règles pour que votre outil de synthèse infère la présence de mémoires. S'il ne le fait pas, il va remplacer la mémoire par de la logique traditionnelle, ce qui est très couteux en termes de ressources. Le problème est que la façon de faire comprendre que vous avez de la RAM est très dépendant du fabricant du FPGA. Nous allons nous contenter de présenter les techniques associées au constructeur Xilinx pour le moment.
RAM prioritaire à l'écriture
modifierVoici comment procéder si l’on veut cibler un composant Spartan3 :
--Single-Port RAM in Write-First Mode VHDL Coding Example One
-- spartan 3
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity rams_02a is
port (clk : in std_logic;
we : in std_logic;
en : in std_logic;
addr : in std_logic_vector(5 downto 0);
di : in std_logic_vector(15 downto 0);
do : out std_logic_vector(15 downto 0));
end rams_02a;
architecture syn of rams_02a is
type ram_type is array (63 downto 0)
of std_logic_vector (15 downto 0);
signal RAM : ram_type;
begin
process (clk)
begin
if clk'event and clk = '1' then
if en = '1' then
if we = '1' then
RAM(conv_integer(addr)) <= di;
do <= di;
else
do <= RAM( conv_integer(addr));
end if;
end if;
end if;
end process;
end syn;
Et maintenant voici comment procéder pour un composant spartan3E. Pour ce composant il semble qu'une RAM à lecture prioritaire soit plus adaptée :
--Single-Port RAM in Read-First Mode VHDL Coding Example
-- spartan 3E
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity rams_01 is
port (clk : in std_logic;
we : in std_logic;
en : in std_logic;
addr : in std_logic_vector(5 downto 0);
di : in std_logic_vector(15 downto 0);
do : out std_logic_vector(15 downto 0));
end rams_01;
architecture syn of rams_01 is
type ram_type is array (63 downto 0) of std_logic_vector (15 downto 0);
signal RAM: ram_type;
begin
process (clk)
begin
if clk'event and clk = '1' then
if en = '1' then
if we = '1' then
RAM(conv_integer(addr)) <= di;
end if;
do <= RAM(conv_integer(addr)) ;
end if;
end if;
end process;
end syn;
Il serait intéressant de mesurer le coût d'une erreur à ce niveau : que se passe-t-il si l’on ne respecte pas les conseils Xilinx : utiliser un modèle spartan3E sur un spartan3 ?
Nous renvoyons le lecteur à la documentation officielle Xilinx pour qu’il se fasse sa propre idée.
Une mémoire morte
modifierUne mémoire morte est simplement une RAM initialisée. Cette définition est très discutable, mais ce que l’on cherche à dire, c’est que nous utiliserons ce genre de mémoire pour mettre un programme dedans. Il y a bien longtemps, ce rôle était dévolu aux ROMs ou EPROMs puis aux EEPROMS. Aujourd’hui les processeurs ont des instructions pour écrire dans la mémoire programme : celle-ci est donc, comme une RAM, à écriture ou lecture. Nous donnons un exemple VHDL maintenant :
--Single-Port BRAM Initial Contents VHDL Coding Example
--
-- Initializing Block RAM (Single-Port BRAM)
--
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity rams_20a is
port (clk : in std_logic;
we : in std_logic;
addr : in std_logic_vector(5 downto 0);
di : in std_logic_vector(19 downto 0);
do : out std_logic_vector(19 downto 0));
end rams_20a;
architecture syn of rams_20a is
type ram_type is array (63 downto 0) of std_logic_vector (19 downto 0);
signal RAM : ram_type:= (X"0200A", X"00300", X"08101", X"04000", X"08601", X"0233A",
X"00300", X"08602", X"02310", X"0203B", X"08300", X"04002",
X"08201", X"00500", X"04001", X"02500", X"00340", X"00241",
X"04002", X"08300", X"08201", X"00500", X"08101", X"00602",
X"04003", X"0241E", X"00301", X"00102", X"02122", X"02021",
X"00301", X"00102", X"02222", X"04001", X"00342", X"0232B",
X"00900", X"00302", X"00102", X"04002", X"00900", X"08201",
X"02023", X"00303", X"02433", X"00301", X"04004", X"00301",
X"00102", X"02137", X"02036", X"00301", X"00102", X"02237",
X"04004", X"00304", X"04040", X"02500", X"02500", X"02500",
X"0030D", X"02341", X"08201", X"0400D");
begin
process (clk)
begin
if rising_edge(clk) then
if we = '1' then
RAM(conv_integer(addr)) <= di;
end if;
do <= RAM(conv_integer(addr));
end if;
end process;
end syn;
Le fait que le signal "ram_type" soit déclaré comme "array(63 downto 0)" fait que la ROM est remplie à l’envers : la valeur X"0200A" se trouve en adresse 63 tandis que la valeur X"0400D" se trouve en adresse 0.
La première fois que nous avons implanté ce type de programme nous pensions que ce type de mémoire était forcément implantée en BRAM mais comme nous l'expliquons dans un autre livre, ce n’est pas toujours le cas. Cela peut dépendre en fait de la version de l'ISE utilisée !
Technologie Xilinx
modifierTout ce qui a été fait dans ce début de chapitre sur les mémoires est relativement portable : le code est du vrai VHDL et l’on peut donc penser que n’importe quel environnement de développement l'acceptera. Nous allons nous attacher à un cas particulier de mémoires propres à Xilinx. Vous rencontrerez plusieurs fois le bandeau de définition ci-dessous dans ce document mais cette terminologie est très importante.
On appellera dans la suite :
- RAMB4 un RAM/ROM de 4 kbits
- RAMB16 un RAM/ROM de 16 kbits (2 ko)
- RAMB16_S18 une RAMB16 avec 18 bits de données (2 ko) : 16 bits et deux bits de parité non utilisés pour nos besoins mais qui le sont pour le picoBlaze.
- RAMB16_S18_S9 une RAMB16 avec deux PORTs indépendants 18 bit de données (16 kbits) pour le PORT appelé "A" et 9 bits pour le PORT appelé B.
À notre connaissance ces RAMB16 existent encore dans les FPGA plus modernes comme les Spartan 6. Par contre ils peuvent avoir jusqu'à 4 PORTs indépendants mais certains sont limités en lecture seulement. Cette augmentation du nombre de PORTs indépendants permet d’éviter d’utiliser de la DMA. Nous avons eu l’occasion de partager une RAM entre un processeur et une petite carte vidéo par exemple.
À partir de maintenant, nous allons examiner les différentes techniques en les classant par projet. Cela permettra au lecteur intéressé par un projet particulier de pouvoir se déplacer directement à son projet et de lire ce qui a été fait.
- Si vous désirez adapter ce qui est traité ici à un autre cœur non évoqué ici, lisez la section concernant le PIC. Elle n’est pas très étoffée mais elle explique partiellement comment utiliser data2mem à partir de fichier HEX.
- Si vous désirez adapter la programmation par liaison série à un autre fondeur que Xilinx, nous n'avons pas encore grand chose à vous conseiller. Espérons que cela changera dans le futur.
Projet picoBlaze
modifierCette section est dédiée au picoBlaze et à toutes les méthodes que l’on peut envisager pour le programmer.
Utiliser data2mem en sept étapes pour le PicoBlaze
modifierCette section est une traduction d'un document écrit par Ken Chapman (qui a conçu le picoBlaze) mais nous ne l'avons pas encore testée.
- Faire votre implantation avec l'ISE, cela vous donnera 3 fichiers importants parmi d'autres :
- design_name.ncd - fichier général de données pour le FPGA
- design_name.bit
- program.psm - programme en assembleur pour PicoBlaze.
- Copier les fichiers 'PB_BMM.EXE' et 'change_pb_bits.bat' dans votre répertoire de travail.
- Opérer les changements de votre programme.
- Ouvrir une fenêtre DOS dans votre répertoire de travail.
- Exécuter le fichier bat en utilisant la commande (noter l'absence d'extensions)...
change_pb_bits progname design_name
- En supposant un assemblage correct de votre programme, vous verrez apparaître les noms d'instance de tous les blocs mémoire de votre conception. Entrer le nombre de BRAM associé à votre programme.
- Un nouveau fichier .bit sera automatiquement généré mais précédé par 'new_' (e.g. new_design_name.bit) que vous pouvez charger avec Impact (outil de chargement dans le FPGA).
Il est facile de remarquer que la description ci-dessus ne fonctionne que sous Windows. Sous Linux, Nous pensons que tous les outils existent mais probablement pas le fichier batch ! Ce qui est nécessaire est un fichier MEM en fait, cela veut dire que sous Linux quand vous exportez avec kpicosim, il faut choisir le fichier .mem. PB_BMM permet de fabriquer le fichier .BMM à partir du fichier .NCD. Une recherche rapide ne m'a pas permis de trouver PB_BMM sous Linux !!!!
Utiliser la RS232 pour remplir la mémoire programme du picoBlaze
modifierNous avons l'intention dans ce chapitre d'examiner la possibilité de remplir la mémoire programme du PicoBlaze à l'aide de la liaison série. Ce problème est très lié à Xilinx et nous utiliserons donc les logicores du chapitre sur la RS232 précédent.
Nous avons fini par abandonner l’utilisation du picoBlaze. Cette section restera donc comme cela sauf si un lecteur veut bien la compléter.
Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?Projet coreATMega8
modifierLe coreATMega8 est décrit dans le chapitre Embarquer un Atmel ATMega8 et sa chaine de compilation est particulièrement examinée dans Annexe I (transformer un fichier HEX en VHDL). Nous reproduisons sa figure correspondante ici :
Il est facile de rester coi devant cette figure en n'en comprenant pas vraiment le sens. Il y a un aspect séquentiel qu'il est difficile de représenter :
- d'abord j'utilise l'ISE pour réaliser le fichier d'extension .bit
- je compile le code source en c pour faire le fichier .elf
- j'utilise directement data2mem pour insérer le programme .elf au bon endroit dans le fichier .bit (à l'aide du fichier .bmm)
- je télécharge le fichier .bit avec Impact ou autre
Seules les trois dernières étapes qui sont très rapides sont nécessaires pour modifier un programme si la partie matérielle est déjà réalisée.
Le problème évoqué à la section précédente est de réaliser le fichier memory.bmm (qui apparait dans la figure ci-dessus) et qui correspond à notre processeur softcore ! Pour éviter de chercher nous le donnons tout construit :
// Pour spartan3 et spartan3E seulement
ADDRESS_SPACE memory_AVR_rom0 RAMB16 [0x00000000:0x00003FFF]
BUS_BLOCK
cpu/opcf/pmem/pe_1 [7:4] PLACED = X1Y2;
cpu/opcf/pmem/pe_0 [3:0] PLACED = X0Y3;
cpu/opcf/pmem/pe_3 [15:12] PLACED = X1Y3;
cpu/opcf/pmem/pe_2 [11:8] PLACED = X0Y2;
cpu/opcf/pmem/po_1 [23:20] PLACED = X1Y0;
cpu/opcf/pmem/po_0 [19:16] PLACED = X0Y0;
cpu/opcf/pmem/po_3 [31:28] PLACED = X1Y1;
cpu/opcf/pmem/po_2 [27:24] PLACED = X0Y1;
END_BUS_BLOCK;
END_ADDRESS_SPACE;
Ce sont les valeurs derrière le mot clé "PLACED" qu’il faut être capable de retrouver. Nous avons eu l’occasion d’utiliser deux versions de l'outil de synthèse et les deux versions nous ont donné des valeurs de placement différentes (pour un même FPGA). Nous les avons trouvé à l'aide de l'outil PlanAhead (visualisation des cellules FPGA utilisées) en cherchant dans les netlists les RAMB4_S4_S4 correspondant au programme.
Un exemple PlanAhead est présenté ci-contre : le principe est simple vous cherchez les BRAM dans la partie gauche (les netlists) et si vous cliquez dessus on vous présente en blanc dans le FPGA où se trouve le composant en question. Et mieux encore dans une partie non présentée dans la figure, on vous donne la localisation exacte dans le FPGA, autrement dit les valeurs dont vous avez besoin pour mettre après le mot clé "PLACED".
C'est le genre de travail qu’il est difficile à faire quand on débute, surtout que PlanAHaed est, à mon avis, assez mal documenté.
Voici en image la description de ce que je viens de dire : trouvez les bulles dans l'ordre, "je choisis ici", "Je suis ici" et "J’ai besoin de cela". Par rapport à l'exemple précédent on a ajouté la partie très utile pour trouver l'emplacement physique des ROMs qui nous montre que la première "RAMB4_S4_S4" est en "X0Y0".
Plutôt que d’utiliser planAhead vous pouvez tout simplement ajouter le fichier bmm dans votre projet en retirant les LOC= mais en laissant le ";". ISE vous générera un autre fichier bmm (votreFichier.bmm génnérera votreFichier_bd.bmm) avec les locations remplies. Par exemple, dans un autre projet, nous avions utilisé le fichier
ADDRESS_SPACE prgmem RAMB16 [0x00000000:0x00001FFF]
BUS_BLOCK
prgmem/pe_0 [3:0] ;
prgmem/pe_1 [7:4] ;
prgmem/pe_2 [11:8] ;
prgmem/pe_3 [15:12];
END_BUS_BLOCK;
END_ADDRESS_SPACE;
et l'ISE nous a généré :
// BMM LOC annotation file.
//
// Release 14.5 - P.58f, build 3.0.7 Mar 3, 2013
// Copyright (c) 1995-2015 Xilinx, Inc. All rights reserved.
///////////////////////////////////////////////////////////////////////////////
//
// Address space 'prgmem' 0x00000000:0x00001FFF (8 KBytes).
//
///////////////////////////////////////////////////////////////////////////////
ADDRESS_SPACE prgmem RAMB16 [0x00000000:0x00001FFF]
BUS_BLOCK
prgmem/pe_0 RAMB16 [3:0] [0:4095] PLACED = X0Y0;
prgmem/pe_1 RAMB16 [7:4] [0:4095] PLACED = X1Y4;
prgmem/pe_2 RAMB16 [11:8] [0:4095] PLACED = X0Y2;
prgmem/pe_3 RAMB16 [15:12] [0:4095] PLACED = X1Y6;
END_BUS_BLOCK;
END_ADDRESS_SPACE;
Ce fichier a été réalisé avec les contraintes
INST prgmem/pe_0 LOC = RAMB16_X0Y0; INST prgmem/pe_1 LOC = RAMB16_X1Y4; INST prgmem/pe_2 LOC = RAMB16_X0Y2; INST prgmem/pe_3 LOC = RAMB16_X1Y6;
dans le fichier UCF.
Il est possible de n'utiliser aucune contrainte dans le fichier ucf, c’est alors le compilateur qui placera où il veut et mettra votre fichier BMM à jour en lui ajoutant, comme dans la remarque précédente, "_bd" avant le ".bmm". Cela est très utile si planHead ne fonctionne pas.
Une fois ce fichier réalisé, il faut le retirer du projet : il n'y a donc pas lieu de garder de fichier bmm dans le projet mais par contre il serait bon de transformer les positions trouvées dans le fichier bmm en contraintes dans le fichier ucf pour éviter toute mauvaise surprise.
Utiliser des RAMB16_S4_S4 avec data2mem
modifierFinalement après avoir tourné en rond pendant près d'un mois (heureusement pas à plein temps), nous avons abandonné l’utilisation des RAMB4_S4_S4 propres au Spartan2 pour utiliser les RAMB16_S4_S4 du spartan 3 mais ceci a comme conséquence une modification de certains fichiers du cœur. Le fichier BMM donné plus haut correspond à cette option.
En 2011, nous avions laissé les codes sources de cette modification directement dans cette section. Mais nous avons décidé de les retirer car nous avons fait trop de modifications en dehors des fichiers qui étaient ici.
Pour avoir la dernière version, télécharger le fichier arduinoMega8.zip contient la version avec la nouvelle instruction SPM. Vous pouvez l’utiliser normalement (avec data2mem). Nous y avons aussi inséré la possibilité de réaliser une mise à 0 automatique d'un drapeau d'interruption, comme pour l'ATMega16 d'un autre chapitre. Ceci est mis en œuvre dans le fichier io_timer.vhd.
Rappelons encore que c’est la version la plus à jour de l'ATMega8.
Après téléchargement vous trouverez le cœur complet. Il ne doit contenir que 19 fichiers (18 en vhdl et 1 seul ucf) Il y a plus que 19 fichiers fournis, mais vous devrez choisir un seul parmi io.vhd io_timer.vhd io_corcic.vhd à mettre dans le projet. De même un seul ucf sera à utiliser. Dans le sous-répertoire soft vous avez quelques scripts qui utilisent data2mem et des fichiers sources. Il vous faudra adapter les scipts :
- à votre FPGA spartan3, spartan3E ou spartan6 (is sont pour spartan6 par défaut)
- à votre système d'exploitation (ceux fournis ne fonctionnent que pour LINUX).
Si vous ne voulez pas avoir de problème avec votre version d'ISE qui ne placera pas forcément les BRAM au même endroit que pour nous, vous pouvez donner des contraintes de placement dans votre fichier ucf :
INST cpu/opcf/pmem/pe_1 LOC = RAMB16_X1Y2; INST cpu/opcf/pmem/pe_0 LOC = RAMB16_X0Y3; INST cpu/opcf/pmem/pe_3 LOC = RAMB16_X1Y3; INST cpu/opcf/pmem/pe_2 LOC = RAMB16_X0Y2; INST cpu/opcf/pmem/po_1 LOC = RAMB16_X1Y0; INST cpu/opcf/pmem/po_0 LOC = RAMB16_X0Y0; INST cpu/opcf/pmem/po_3 LOC = RAMB16_X1Y1; INST cpu/opcf/pmem/po_2 LOC = RAMB16_X0Y1;
Cela vous évitera de changer le fichier bmm donné plus haut !
Ces contraintes fonctionnent pour la carte Spartan3, Spartan3E, Basys2 et probablement Nexys2 de chez Digilent.
Elles ne fonctionnent pas par contre pour la carte Nexys3 (équipée d'un spartan6). Nous les avons changé comme :
INST cpu/opcf/pmem/pe_1 LOC = RAMB16_X1Y2; INST cpu/opcf/pmem/pe_0 LOC = RAMB16_X0Y4; INST cpu/opcf/pmem/pe_3 LOC = RAMB16_X1Y6; INST cpu/opcf/pmem/pe_2 LOC = RAMB16_X0Y2; INST cpu/opcf/pmem/po_1 LOC = RAMB16_X1Y0; INST cpu/opcf/pmem/po_0 LOC = RAMB16_X0Y0; INST cpu/opcf/pmem/po_3 LOC = RAMB16_X1Y4; INST cpu/opcf/pmem/po_2 LOC = RAMB16_X0Y6;
ainsi que le fichier memory.bmm correspondant (renommé memoryS6.bmm pour l’occasion) :
// Pour spartan6
ADDRESS_SPACE memory_AVR_rom0 RAMB16 [0x00000000:0x00003FFF]
BUS_BLOCK
cpu/opcf/pmem/pe_1 [7:4] PLACED = X1Y2;
cpu/opcf/pmem/pe_0 [3:0] PLACED = X0Y4;
cpu/opcf/pmem/pe_3 [15:12] PLACED = X1Y6;
cpu/opcf/pmem/pe_2 [11:8] PLACED = X0Y2;
cpu/opcf/pmem/po_1 [23:20] PLACED = X1Y0;
cpu/opcf/pmem/po_0 [19:16] PLACED = X0Y0;
cpu/opcf/pmem/po_3 [31:28] PLACED = X1Y4;
cpu/opcf/pmem/po_2 [27:24] PLACED = X0Y6;
END_BUS_BLOCK;
END_ADDRESS_SPACE;
Petit résumé de ce que nous savons faire à ce point
modifierVotre partie matérielle est complètement réalisée et compilée. Vous avez donc à votre disposition un fichier BIT et l'outil data2mem va être chargé de modifier le fichier BIT à partir d'une compilation de votre nouveau programme source supposé être en C pour la suite des explications.
- Nous commençons par compiler notre programme c pour obtenir un fichier au format ELF :
avr-gcc -g -mmcu=atmega8 -Wall -Os -c hello.c avr-gcc -g -mmcu=atmega8 -o hello.elf -Wl,-Map,hello.map hello.o
- Nous écrivons notre ficher BMM donné plus haut à l'aide d'un éditeur de texte
- nous lançons data2mem :
data2mem -bm memory.bmm -bd hello.elf -bt avr_fpga.bit -o uh avr_fpga
Pour nous un nouveau fichier BIT est créé : avr_fpga_rp.bit.
Ce nom est probablement un nom par défaut de data2mem puisque nous n'utilisons pas l'option "-o b" pour donner un nouveau nom. L'option proposée ici "-o h" génère un fichier VHDL qui nous a été utile pour construire le fichier BMM ! Si donc vous remplacez "-o h" par "-o b" votre fichier BIT créé s'appellera "new_avr_fpga.bit".
- Le fichier avr_fpga_rp.bit est chargé dans le FPGA
Un petit script peut faire le travail complet :
#!/bin/bash
#pour spartan6
#export PATH=$PATH:/usr/local/avr/bin:~/XILINX/Xilinx/11.1/ISE/bin/lin/
export PATH=$PATH:/opt/Xilinx/14.5/ISE_DS/ISE/bin/lin64
avr-gcc -g -mmcu=atmega8 -Wall -Os -c hello.c
avr-gcc -g -mmcu=atmega8 -o hello.elf -Wl,-Map,hello.map hello.o
avr-objdump -h -S hello.elf > hello.lss
#avr-objcopy -O binary -R .eeprom hello.elf hello.bin
#avr-objcopy -R .eeprom -O ihex hello.elf hello.hex
data2mem -bm memoryS6.bmm -bd hello.elf -bt avr_fpga.bit -o uh avr_fpga
djtgcfg prog -d Nexys3 --index 0 --file avr_fpga_rp.bit
à condition d’avoir ADEPT installé (ADEPT est l'utilitaire de Digilent pour télécharger dans le FPGA).
Sur un PC acheté en 2002, la compilation complète de l'AVR prend environ 10 minutes alors que les opérations ci-dessus en prennent à peine une ! Il est probable que certains lecteurs trouvent rétro d’utiliser un PC si vieux... pourtant nous n'aurions jamais écrit cette section si nous ne nous étions pas trouvé avec des temps de compilation énormes. Nous avons eu un tel mal à trouver le bon fichier BMM que nous aurions sans doute abandonné en cours de route si notre seul objectif était de gagner seulement quelques minutes... Mais pour en gagner près de dix, le jeu en valait la chandelle.
Quelle que soit votre opinion, maintenant le travail est fait et, pour ne rien gâcher, publié et accessible gratuitement...
Utiliser la RS232 et un bootloader pour ATMega8
modifierNote : Cette section ne débouche malheureusement pas sur un ensemble fonctionnant correctement. Nous allons abandonner sa rédaction pour un temps comme nous l'avons fait déjà l'année précédente à la même époque pour nous consacrer à d'autres parties (de ce livre). Ce que nous espérons faire dans le futur :
- Réimplanter l'instruction SPM pour qu'elle soit plus conforme à celle des ATMega (Nous avons fait un pas en avant le 7 juillet 2015 après deux ans (pas à plein temps).... Soyez donc patient)
- Faire fonctionner le bootloader Arduino
Avant de s'intéresser à notre problème particulier, nous allons passer en revue le problème du bootloader dans les Atmel AVR commercialisés. Le mot bootloader est traduit par Chargeur d'amorçage dans Wikipédia mais nous n'utiliserons pas cette terminologie.
Le bootloader dans les AVR
modifierL'idée est de réaliser ce que l’on trouve dans le petit système de développement appelé (en) Butterfly ou dans l’Arduino. Ces systèmes très bon marché sont architecturés autour d'un bootloader, c'est-à-dire un petit programme qui démarre le processeur en attendant qu'un ensemble de données lui arrive par la RS232. S'il y a des données, elles correspondent à un programme et le bootloader sera chargé de modifier la mémoire programme en conséquence. Tout ceci est bien plus facile à dire qu’à faire. Nous voyons un certain nombre de questions auxquelles il nous faut répondre pour continuer ce travail :
- le programme bootloader est-il dans un endroit particulier ?
- peut-on envoyer directement un fichier hex ?
Pour la première question, oui le bootloader est dans un endroit particulier qui semble dépendre de la famille des AVR. Un bootloader de l'Arduino pour l'ATMega8 contient
--section-start=.text=0x1C00
dans son makefile, ce qui montre très clairement qu’il est à un endroit très précis. En général le bootloader est en mémoire haute. Sa taille est classiquement 1 ou 2 ko.
Pour la deuxième question, il n'y a pas de réponse générale. Tout dépend du protocole, donc du code source du bootloader (et du programmateur). Par exemple le protocole STK500 envoie les programmes à écrire dans la mémoire flash en binaire. C'est le programmateur sur PC qui s'occupe de la transformation hex vers binaire (pour nous avrdude)
Nous pensons que les explications données sont suffisantes pour une compréhension de ce qui va suivre. Si vous voulez d'autres informations plus générales nous avons créé un chapitre dédié aux bootloaders dans les AVR (pas très avancé) dans un autre projet : Les microcontrôleurs AVR.
Avant Juillet 2015
modifierL'instruction SPM a été implantée en 2011 mais de manière trop différente de celle de l'ATMega8 du commerce pour envisager l’utilisation d'un bootloader existant. Voici comment elle était implantée :
L'instruction SPM implantée dans le cœur et testée par le programme ci-dessus fonctionne de la manière suivante :
- Donnée (8 bits) dans R0
- Adresse d'écriture (16 bits) dans R31:R30
- Le registre SPMCR n’est pas utilisé !
- Le registre R1 n’est pas utilisé !!!
C'est ce dernier point sur le registre R1 qui sera changé un petit peu plus loin dans ce chapitre.
Il faut d’autre part avoir à l'esprit que vous pourrez faire fonctionner un bootloader sur un processeur qu’à une condition : qu’il ait une instruction pour pouvoir écrire dans la mémoire programme. C'est le cas pour l'ATMega8, l'instruction en question s’appelle SPM. La version correspondante du cœur se trouve dans le répertoire /AVRComplet16_S4_S4/25MHzAVR/ du fichier ATMega8_pong_VGA.zip qui contient une version améliorée du processeur, capable de gérer les interruptions et l'instruction SPM.
Mais ...
|
La version téléchargeable chez OpenCore ne gère pas l'instruction SPM !!! en tout cas pour le moment (14 juillet 2011 à 14:21 UTC) et c’était encore le cas en Juillet 2015 : Juergen Sauermann, auteur du cœur, nous a dit qu’il ne pouvait plus accéder pour modification au site Opencores.org. Nous continuerons à gérer toutes ces versions avec notre site personnel, mais il nous faudra bien un jour trouver une autre solution ! |
Intéressons-nous maintenant à la façon dont nous allons réaliser les choses dans notre coreATMega8.
Protocole STK500v1 de l'Arduino
modifierNous avons comme rêve de réaliser un protocole STK500 et un bootloader correspondant dans notre cœur ATMega8. L'intérêt serait de programmer notre FPGA directement à partir de l'environnement Arduino ou même de l'environnement AVRStudio (remplacé par MPLABX depuis l'achat d' ATMEL par Microchip).
À ce jour nous n'avons pas réussi à le réaliser. Mais nous pensons qu’il est intéressant de discuter les raisons de cet échec et ce qu’elles nous ont appris. Et nous n'avons pas abandonné l’idée de le faire fonctionner un jour... et ce projet progresse petit à petit.
Comme base de travail nous nous sommes servi du fichier source "/usr/share/arduino/hardware/arduino/bootloaders/atmega8/ATmegaBOOT.c" C'est un bootloader pour ATMega8. Nous avons réussi à le faire fonctionner mais le programme chargé ne démarre pas convenablement. Ainsi le programmateur avrdude croit discuter avec un Arduino. Dès que l'instruction SPM du bootloader est mise en commentaire, le dialogue entre notre ATMega8 et l'environnement Arduino se passe très bien. D'ailleurs ce même environnement ne sait même pas que rien n'a été écrit en mémoire programme...
Quant à la routine d'écriture en mémoire programme, nous avons déjà réussi à la faire fonctionner dans un autre contexte... mais pas correctement ici. Nous suspectons très fortement l'instruction ATMega8 SPM de ne pas avoir été implantée de manière suffisamment large pour un bootloader.
Documentation de l'instruction SPM
modifierL'article AVR106: C functions for reading and writing to Flash memory précise que l'écriture dans la mémoire programme Flash se fait en trois étapes :
- écriture d'une page de 32 mots dans une mémoire tampon
- effacement de la page en mémoire Flash
- transfert du tampon dans la mémoire flash.
Tout ceci est contrôlé par le registre associé à l'instruction SPM : SPMCR.
Nous avons d’autre part trouvé les informations complémentaires suivantes en lisant le code source du bootloader Arduino :
- Une page pour l'ATMega8 est composée de 32 mots (64 octets).
- Le registre Z est R31:R30 (auxquels on ajoute RAMPZ parfois) contient l'adresse où l’on veut écrire.
- Le registre SPMCR est en adresse 0x37(0x57) est à implanter. Il sert à contrôler l'instruction SMP. Par exemple si l’on écrit 3 dedans avant SPM il effacera une page (pointée par Z), si l’on écrit 0x05 il écrira une page (pointée par Z) mais il faut le repasser en mode RWW avec 0x11 (dans SPMCR) auparavant, et en appelant SPM. S'il est mis à 1 cela met R1:R0 dans le registre temporaire de la Flash (pointé par le poids faible de Z).
- R29:R28 contient l'adresse du buffer en RAM
- R25:R24 contient la longueur à écrire
Donc, pour écrire un mot dans le buffer de page, charger le mot dans le registre R1:R0. S'arranger pour que le registre Z pointe sur le mot correct (bits b5 ... b1 [b0 est ignoré car on travaille en mots]) et mettre seulement le bit SPMEN du registre SPMCR et avant 4 cycles appler SPM.
|
|
La gestion des adresses mémoire programme nous a posé des problèmes suffisamment longtemps pour que nous décidions d'y attirer votre attention. Le compilateur C gère les mémoires avec des adresses d'octets. Votre matériel les gère en adresse de mots de 16 bits. Il y a donc un facteur 2 entre les deux. Ainsi une compilation avec l'option de placer le bootloader en 0x1C00 (vu par le compilateur) est associée à une initialisation matérielle en 0x0E00 qui est 0x1C00/2. Nous n'avons pas réussi à faire fonctionner data2mem pour qu’il mette le bootloader à l'endroit voulu !!! Il était toujours en adresse 0x0000 malgré la bonne option de compilation. Probablement une option à chercher. Par contre nous avons réussi à le mettre à l'endroit voulu avec l'outil primitif make_mem ! |
Nouvelle instruction SPM (Juillet 2015)
modifierNous avons modifié l'instruction SPM comme suit :
L'instruction SPM implantée dans le cœur en Juillet 2015 fonctionne de la manière suivante :
- Donnée (16 bits) dans R1:R0
- Adresse d'écriture (16 bits) dans R31:R30 (appelé Z en assembleur)
- Le registre SPMCR n’est pas utilisé !
Cette implantation ne permet pas d’utiliser un bootloader tout fait car on y trouve des attentes sur le registre SPMCR qui ne fonctionne pas dans notre cas.
Le 7 juillet 2015, nous avons enfin réussi à faire fonctionner le programme :
#include <inttypes.h>
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <avr/eeprom.h>
#include <avr/interrupt.h>
#define F_CPU 50000000L
#include <util/delay.h>
#define BAUD_RATE 19200
#ifndef outb
#define outb(sfr,val) (_SFR_BYTE(sfr) = (val))
#endif
#ifndef inb
#define inb(sfr) _SFR_BYTE(sfr)
#endif
/* defines for future compatibility */
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif
void putch(char ch);
void usart_puts_hexa(int nbQ3_13);
inline void pgm_write_byte(uint16_t addr, uint16_t value);
uint16_t address;
int main(void) {
PORTC = 0x00;
/* initialize UART(s) depending on CPU defined */
/* m8 */
UBRRH = (((F_CPU/BAUD_RATE)/16)-1)>>8; // set baud rate
UBRRL = (((F_CPU/BAUD_RATE)/16)-1);
UCSRB = (1<<RXEN)|(1<<TXEN); // enable Rx & Tx
UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // config USART; 8N1
putch('O');
putch('O');
putch('O');
putch('K');
putch('-');
putch('-');
putch('-');
putch('-');
putch(0x0D);putch(0x0A);
address=0x0400;
// pgm_write_byte(address, 0xAA55);
// pgm_write_byte(address+2, 0xAA55);
for(address=0x0400;address<0x0410;address += 2) {
uint16_t temp;
temp = 0xAA;
temp <<= 8;
temp += 0x55;
pgm_write_byte(address,temp);
}
// recherche de la chaine 0x55AA en mémoire :
address = 0x0000;
do {
if ((pgm_read_byte(address)==0x55) && (pgm_read_byte((address)+1)==0xAA) /* && (pgm_read_byte((address)+2)==0x55) && (pgm_read_byte((address)+3)==0xAA)*/) {
putch('O');
putch('K');
putch(':');
usart_puts_hexa(address);
putch('-');
putch('-');
putch('-');
putch(0x0D);putch(0x0A);
}
address++;
if (address > 0x1000) {
address = 0x0000;
putch('F');
putch('I');
putch('N');
putch('-');
putch('-');
putch('-');
putch('-');
putch('-');
putch(0x0D);putch(0x0A);
_delay_ms(1000);
}
} while (1);
return 0;
}
void putch(char ch)
{
/* m8 */
while (!(inb(UCSRA) & _BV(UDRE)));
outb(UDR,ch);
}
//************************************************************************
// function usart_puts_hexa()
// purpose: puts number in hexadecimel in first rs232 PORT
// arguments:
// corresponding number
// return:
// note: 38400,8,n,2 hard coded : transmission
// initialisation uart prealable requise
// only for 16-bit numbers and then Q3.13 numbers
//************************************************************************
void usart_puts_hexa(int nbQ3_13){
int8_t i=0,digit=0;
char char_digit;
putch('0');putch('X');
for (i=12;i>-1;i-=4) {// only four digits
digit = (nbQ3_13 >> i) & 0x0F;
char_digit=digit+0x30;
if (char_digit>0x39) char_digit += 7;
putch(char_digit);
}
}
//inline void pgm_write_byte(const char * addr, uint8_t value)
inline void pgm_write_byte(uint16_t addr, uint16_t value)
{
__asm__ volatile (
"push r0" "\n\t"
"push r1" "\n\t"
// "push r30" "\n\t"
// "push r31" "\n\t"
"movw r0, %1" "\n\t"
"spm" "\n\t"
// "pop r31" "\n\t"
// "pop r30" "\n\t"
"pop r1" "\n\t"
"pop r0" "\n\t"
:: "z" (addr), "w" (value) : //"r0","r1" // "z" utilise r31:r30
);
}
où la seule partie intéressante est le main.
Ce programme écrit d'abord le mot "0xAA55" en mémoire programme dans des adresses consécutives, puis cherche ce même mot en affichant où il l'a trouvé. Excellent donc pour une vérification. Il montre que nous avons enfin réussi à faire cohabiter les instructions SPM et LPM. Cela peut sembler anodin, mais le fait que LPM travaille sur des adresses mémoires (programme) qui adressent des octets tandis que SPM adresse des mots nous a posé beaucoup de soucis. Désolé mais il ne faut pas grand chose parfois pour bloquer la mécanique.
Ce programme fonctionne normalement qu’il soit en adresse basse (comme un programme normal) ou en adresse haute (comme un bootloader). Pour info, la mise de ce programme en adresse haute se fait par :
export PATH=$PATH:/opt/Xilinx/14.5/ISE_DS/ISE/bin/lin64 avr-gcc -g -mmcu=atmega8 -Wall -Os -c ATmegaBOOT2.c avr-gcc -g -mmcu=atmega8 -o ATmegaBOOT.elf -Wl,-Map,ATmegaBOOT.map,--section-start=.text=0x1C00 ATmegaBOOT2.o avr-objcopy -R .eeprom -O ihex ATmegaBOOT.elf ATmegaBOOT.hex ./make_mem ATmegaBOOT.hex prog_mem_content.vhd cp prog_mem_content.vhd ../../prog_mem_content.vhd #a adapter pour vous : prog_mem_content doit se trouver dans le projet vhdl
- mise à true du generic BootLoader dans cpu_core.vhd pour qu'un reset l'emmène dans le bootloader
- compilation totale du projet VHDL
- chargement du fichier .bit
Ainsi, il est possible maintenant d'adapter le bootloader Arduino... Affaire à suivre....
Bootloader Arduino modifié
modifierPuisque notre instruction SPM n’est pas conforme à celle de l'ATMega8 du commerce, il nous faut changer le bootloader. Par exemple le bootloader des premiers Arduino ATMega8 attend avant chaque instruction SPM que certains bits du registre de contrôle SPMCR passent à 1. Puisque nous ne gérons absolument pas ce registre, le code du bootloader est à changer... Voici donc une version modifiée du bootloader :
/**********************************************************/
/* Serial Bootloader for Atmel mega8 AVR Controller */
/* */
/* ATmegaBOOT.c */
/* */
/* Copyright (c) 2003, Jason P. Kyle */
/* */
/* Hacked by DojoCorp - ZGZ - MMX - IVR */
/* Hacked by David A. Mellis */
/* */
/* This program is free software; you can redistribute it */
/* and/or modify it under the terms of the GNU General */
/* Public License as published by the Free Software */
/* Foundation; either version 2 of the License, or */
/* (at your option) any later version. */
/* */
/* This program is distributed in the hope that it will */
/* be useful, but WITHOUT ANY WARRANTY; without even the */
/* implied warranty of MERCHANTABILITY or FITNESS FOR A */
/* PARTICULAR PURPOSE. See the GNU General Public */
/* License for more details. */
/* */
/* You should have received a copy of the GNU General */
/* Public License along with this program; if not, write */
/* to the Free Software Foundation, Inc., */
/* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */
/* */
/* Licence can be viewed at */
/* http://www.fsf.org/licenses/gpl.txt */
/* */
/* Target = Atmel AVR m8 */
/**********************************************************/
#include <inttypes.h>
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <avr/eeprom.h>
#include <avr/interrupt.h>
//#define F_CPU 16000000
#define F_CPU 50000000L
#include <util/delay.h>
/* We, Malmoitians, like slow interaction
* therefore the slow baud rate ;-)
*/
//#define BAUD_RATE 9600
#define BAUD_RATE 19200
/* 6.000.000 is more or less 8 seconds at the
* speed configured here
*/
//#define MAX_TIME_COUNT 6000000
#define MAX_TIME_COUNT (F_CPU>>1)
///#define MAX_TIME_COUNT_MORATORY 1600000
/* SW_MAJOR and MINOR needs to be updated from time to time to avoid warning message from AVR Studio */
#define HW_VER 0x02
#define SW_MAJOR 0x01
#define SW_MINOR 0x12
// AVR-GCC compiler compatibility
// avr-gcc compiler v3.1.x and older doesn't support outb() and inb()
// if necessary, convert outb and inb to outp and inp
#ifndef outb
#define outb(sfr,val) (_SFR_BYTE(sfr) = (val))
#endif
#ifndef inb
#define inb(sfr) _SFR_BYTE(sfr)
#endif
/* defines for future compatibility */
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif
/* Adjust to suit whatever pin your hardware uses to enter the bootloader */
#define eeprom_rb(addr) eeprom_read_byte ((uint8_t *)(addr))
#define eeprom_rw(addr) eeprom_read_word ((uint16_t *)(addr))
#define eeprom_wb(addr, val) eeprom_write_byte ((uint8_t *)(addr), (uint8_t)(val))
/* Onboard LED is connected to pin PB5 */
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_PIN PINB
#define LED PINB5
#define SIG1 0x1E // Yep, Atmel is the only manufacturer of AVR micros. Single source :(
#define SIG2 0x93
#define SIG3 0x07
#define PAGE_SIZE 0x20U //32 words
void putch(char);
char getch(void);
void getNch(uint8_t);
void byte_response(uint8_t);
void nothing_response(void);
int main2(void);
void print_PM_content(void);
void usart_puts_hexa(int nbQ3_13);
inline void pgm_write_byte(uint16_t addr, uint16_t value);
union address_union {
uint16_t word;
uint8_t byte[2];
} address;
union length_union {
uint16_t word;
uint8_t byte[2];
} length;
struct flags_struct {
unsigned eeprom : 1;
unsigned rampz : 1;
} flags;
uint8_t buff[256];
//uint8_t address_high;
uint8_t pagesz=0x80;
uint8_t i;
//uint8_t bootuart0=0,bootuart1=0;
void (*app_start)(void) = 0x0400; // 0x0800/2 est obligatoire !!!!
//void (*app_start)(void) = 0x0000;
int main(void)
{
uint8_t ch,ch2;
uint16_t w;
asm volatile("nop\n\t");
/* initialize UART(s) depending on CPU defined */
/* m8 */
UBRRH = (((F_CPU/BAUD_RATE)/16)-1)>>8; // set baud rate
UBRRL = (((F_CPU/BAUD_RATE)/16)-1);
UCSRB = (1<<RXEN)|(1<<TXEN); // enable Rx & Tx
UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // config USART; 8N1
//UBRRL = (uint8_t)(F_CPU/(BAUD_RATE*16L)-1);
//UBRRH = (F_CPU/(BAUD_RATE*16L)-1) >> 8;
//UCSRA = 0x00;
//UCSRC = 0x86;
//UCSRB = _BV(TXEN)|_BV(RXEN);
/* this was giving uisp problems, so I removed it; without it, the boot
works on with uisp and avrdude on the mac (at least). */
/* set LED pin as output */
sbi(LED_DDR,LED);
for (i = 0; i < 16; i++) {
outb(LED_PORT, inb(LED_PORT) ^ _BV(LED));
_delay_loop_2(0);
}
/* see comment at previous call to putch() */
//putch('\0'); // this line is needed for the synchronization of the programmer
/* forever */
for (;;) {
//if((inb(UCSRA) & _BV(RXC))){
/* get character from UART */
ch = getch();
/* A bunch of if...else if... gives smaller code than switch...case ! */
/* Hello is anyone home ? */
if(ch=='0') {
nothing_response();
}
/* Request programmer ID */
/* Not using PROGMEM string due to boot block in m128 being beyond 64kB boundry */
/* Would need to selectively manipulate RAMPZ, and it's only 9 characters anyway so who cares. */
else if(ch=='1') {
if (getch() == ' ') {
putch(0x14);
putch('A');
putch('V');
putch('R');
putch(' ');
putch('I');
putch('S');
putch('P');
putch(0x10);
}
}
/* AVR ISP/STK500 board commands DON'T CARE so default nothing_response */
else if(ch=='@') {
ch2 = getch();
if (ch2>0x85) getch();
nothing_response();
}
/* AVR ISP/STK500 board requests */
else if(ch=='A') {
ch2 = getch();
if(ch2==0x80) byte_response(HW_VER); // Hardware version
else if(ch2==0x81) byte_response(SW_MAJOR); // Software major version
else if(ch2==0x82) byte_response(SW_MINOR); // Software minor version
//else if(ch2==0x98) byte_response(0x03); // Unknown but seems to be required by avr studio 3.56
else byte_response(0x00); // Covers various unnecessary responses we don't care about
}
/* Device Parameters DON'T CARE, DEVICE IS FIXED */
else if(ch=='B') {
getNch(20);
nothing_response();
}
/* Parallel programming stuff DON'T CARE */
else if(ch=='E') {
getNch(5);
nothing_response();
}
/* Enter programming mode */
else if(ch=='P') {
nothing_response();
// FIXME: modified only here by DojoCorp, Mumbai, India, 20050626
//time_count=0; // exted the delay once entered prog.mode
}
/* Leave programming mode */
else if(ch=='Q') {
nothing_response();
//time_count=MAX_TIME_COUNT_MORATORY; // once the programming is done,
// we should start the application
// but uisp has problems with this,
// therefore we just change the times
// and give the programmer 1 sec to react
}
/* Erase device, don't care as we will erase one page at a time anyway. */
else if(ch=='R') {
nothing_response();
}
/* Set address, little endian. EEPROM in bytes, FLASH in words */
/* Perhaps extra address bytes may be added in future to support > 128kB FLASH. */
/* This might explain why little endian was used here, big endian used everywhere else. */
else if(ch=='U') {
address.byte[0] = getch();
address.byte[1] = getch();
// address.word +=0x0800;
nothing_response();
}
/* Universal SPI programming command, disabled. Would be used for fuses and lock bits. */
else if(ch=='V') {
getNch(4);
byte_response(0x00);
}
/* Write memory, length is big endian and is in bytes */
else if(ch=='d') {
length.byte[1] = getch();
length.byte[0] = getch();
flags.eeprom = 0;
if (getch() == 'E') flags.eeprom = 1;
for (w=0;w<length.word;w++) {
buff[w] = getch(); // Store data in buffer, can't keep up with serial data stream whilst programming pages
}
if (getch() == ' ') {
if (flags.eeprom) { //Write to EEPROM one byte at a time
for(w=0;w<length.word;w++) {
eeprom_wb(address.word,buff[w]);
address.word++;
}
} else { //Write to FLASH one page at a time
//if (address.byte[1]>127) address_high = 0x01; //Only possible with m128, m256 will need 3rd address byte. FIXME
//else address_high = 0x00;
//address.word = address.word << 1; //address * 2 -> byte location
//if ((length.byte[0] & 0x01)) length.word++; //Even up an odd number of bytes
cli(); //Disable interrupts, just to be sure
// not at the moment for us while(bit_is_set(EECR,EEWE)); //Wait for previous EEPROM writes to complete
for(w=0;w<(length.word);w += 2) {
uint16_t temp;
temp = buff[w+1];
temp <<= 8;
temp += buff[w];
pgm_write_byte(address.word,temp);
address.word += 2;
}
/* Should really add a wait for RWW section to be enabled, don't actually need it since we never */
/* exit the bootloader without a power cycle anyhow */
}
//PORTC=0x55;
putch(0x14);
putch(0x10);
}
}
/* Read memory block mode, length is big endian. */
else if(ch=='t') {
length.byte[1] = getch();
length.byte[0] = getch();
if (getch() == 'E') flags.eeprom = 1;
else {
flags.eeprom = 0;
address.word = address.word << 1; // address * 2 -> byte location
}
if (getch() == ' ') { // Command terminator
putch(0x14);
for (w=0;w < length.word;w++) { // Can handle odd and even lengths okay
if (flags.eeprom) { // Byte access EEPROM read
putch(eeprom_rb(address.word));
address.word++;
} else {
if (!flags.rampz) putch(pgm_read_byte_near(address.word));
address.word++;
}
}
putch(0x10);
}
}
/* Get device signature bytes */
else if(ch=='u') {
if (getch() == ' ') {
putch(0x14);
putch(SIG1);
putch(SIG2);
putch(SIG3);
putch(0x10);
}
}
/* Read oscillator calibration byte */
else if(ch=='v') {
byte_response(0x00);
}
} /* end of forever loop */
}
void putch(char ch)
{
/* m8 */
while (!(inb(UCSRA) & _BV(UDRE)));
outb(UDR,ch);
}
char getch(void)
{
/* m8 */
uint32_t count = 0;
while(!(inb(UCSRA) & _BV(RXC))) {
/* HACKME:: here is a good place to count times*/
count++;
if (count > MAX_TIME_COUNT) {
//print_PM_content();
app_start();
//main2();
}
}
return (inb(UDR));
}
void getNch(uint8_t count)
{
uint8_t i;
for(i=0;i<count;i++) {
/* m8 */
//while(!(inb(UCSRA) & _BV(RXC)));
//inb(UDR);
getch(); // need to handle time out
}
}
void byte_response(uint8_t val)
{
if (getch() == ' ') {
putch(0x14);
putch(val);
putch(0x10);
}
}
void nothing_response(void)
{
if (getch() == ' ') {
putch(0x14);
putch(0x10);
}
}
/* end of file ATmegaBOOT.c */
/*
int main2(){
PORTC=0xFF;
while(1){
long int nb;
PORTC=0x55;
for(nb=0;nb<2000000;nb++)
PORTB=3;
PORTC=0xAA;
for(nb=0;nb<2000000;nb++)
PORTB=5;
}
return 0;
}
void print_PM_content(void) {
uint16_t address=0x800;
uint16_t opcode;
_delay_ms(5000);
for (;address < 0x860;address+=2) {
opcode = pgm_read_byte(address);
opcode <<= 8;
opcode += pgm_read_byte(address+1);
usart_puts_hexa(opcode);
putch(0x0D);
putch(0x0A);
_delay_ms(1000);
}
}
*/
//************************************************************************
// function usart_puts_hexa()
// purpose: puts number in hexadecimel in first rs232 PORT
// arguments:
// corresponding number
// return:
// note: 38400,8,n,2 hard coded : transmission
// initialisation uart prealable requise
// only for 16-bit numbers and then Q3.13 numbers
//************************************************************************
/*
void usart_puts_hexa(int nbQ3_13){
int8_t i=0,digit=0;
char char_digit;
putch('0');putch('X');
for (i=12;i>-1;i-=4) {// only four digits
digit = (nbQ3_13 >> i) & 0x0F;
char_digit=digit+0x30;
if (char_digit>0x39) char_digit += 7;
putch(char_digit);
}
}
*/
//inline void pgm_write_byte(const char * addr, uint8_t value)
inline void pgm_write_byte(uint16_t addr, uint16_t value)
{
__asm__ volatile (
"push r0" "\n\t"
"push r1" "\n\t"
"push r30" "\n\t"
"push r31" "\n\t"
"movw r0, %1" "\n\t"
"spm" "\n\t"
"pop r31" "\n\t"
"pop r30" "\n\t"
"pop r1" "\n\t"
"pop r0" "\n\t"
:: "z" (addr), "w" (value) : //"r0","r1" // "z" utilise r31:r30
);
}
La complexité du code est due à la gestion du protocole STK500.
Le problème est que ce bootloader fonctionne presque en adresse basse 0x0000 mais moins bien si on le met là où il doit être, c’est-à-dire en adresse haute 0x1C00.
|
|
Les fonctionnements à ce jour sont les suivants :
|
Ressource
modifierLe fichier arduinoMega8.zip contient la version avec la nouvelle instruction SPM. Le fichier progmemcontent.vhd contient le bootloader (qui ne fonctionne pas correctement). Cette version a été réalisée avec l'option bootloader à false, ce qui veut dire que vous pouvez l’utiliser normalement (avec data2mem). Nous y avons aussi inséré la possibilité de réaliser une mise à 0 automatique d'un drapeau d'interruption, comme pour l'ATMega16 d'un autre chapitre. Rappelons que c’est la version la plus à jour.
L'obsession que nous avons à essayer de faire fonctionner le bootloader de cette section est liée à ce qu'une réussite permettrait d’utiliser notre FPGA dans une salle d'enseignement où l'environnement Arduino est installé. Il n'y aurait aucune modification à faire pour l'IDE Arduino. Mais bien sûr une modification matérielle nécessiterait l'ISE de Xilinx.
Comme notre objectif n’est pas encore atteint, nous donnons une variante dans la section suivante qui fonctionne, mais nécessite de changer l'IDE Arduino (plus exactement remplacer avrdude).
Protocole STK500v1 de l'Arduino détourné
modifierEn fait ce que nous voulons réaliser est de pouvoir utiliser l'environnement Arduino et le bouton de téléversement pour charger notre programme dans le FPGA. Un moyen évitant de faire fonctionner un bootloader, est d’utiliser data2mem au lieu de avrdude. Notre collègue Bastien Jacquot avait un problème avec des points communs : programmer un Arduino par le réseau. L’idée générale est la suivante :
- ajouter une carte Arduino factice
- remplacer avrdude par un script qui détecte s'il doit lancer avrdude ou s'il lance d'autres commandes
Voici comment on ajoute une carte Arduino.
- Chercher le fichier "/usr/share/arduino/hardware/arduino/boards.txt" et ajouter à la fin par exemple :
############################################################## Xatmega16.name=Arduino Xilinx ATmega16 Xatmega16.upload.protocol=data2mem Xatmega16.upload.speed=1200 Xatmega16.upload.maximum_size=16384 Xatmega16.upload.disable_flushing=true Xatmega16.build.mcu=atmega16 Xatmega16.build.f_cpu=50000000L Xatmega16.build.core=arduino Xatmega16.build.variant=standard
- Renommer le fichier "/usr/share/arduino/hardware/tools/avrdude" (qui est un lien) en "/usr/share/arduino/hardware/tools/avrdude.arduino".
- Écrire le script et le mettre à la place de "/usr/share/arduino/hardware/tools/avrdude" :
#!/bin/bash
export PATH=$PATH:/opt/Xilinx/14.5/ISE_DS/ISE/bin/lin64
# Octobre 2013 (Bastien Jacquot)
params=$*
echo "Voici la liste des paramètres (un seul argument) : $params"
programmer=avrdude
for param in "$@"
do
if [[ $param == -cdata2mem ]]
then
programmer=data2mem
elif [[ $param == -Uflash:w:* ]]
then
fichier=`echo $param| cut -d":" -f3`
fi
done
if [[$programmer == avrdude]]
then
/usr/share/arduino/hardware/tools/avrdude.arduino $*
elif [[$programmer == data2mem]]
then
fichier=`echo $fichier| sed -e 's/.hex/.elf /g'`
data2mem -bm ~/memoryS6.bmm -bd $fichier -bt ~/atmega16.bit -o uh ~/atmega16
echo "Transfert par ADEPT de $fichier"
djtgcfg prog -d Nexys3 --index 0 --file ~/atmega16_rp.bit
fi
L'idée générale du script est la suivante :
- repérer l’utilisation d'un programmateur data2mem
- dans ce cas retrouver le fichier qui a l'extension .hex et le remplacer par le même fichier avec l'extension .elf
- lancer data2mem
- lancer ADEPT
- autrement lancer avrdude normalement
Ce script nécessite les fichiers atmega16.bit et memmoryS6.bmm présents dans notre répertoire personnel. Il ne fonctionne que pour une carte nexys3.
La réalisation de de ce travail sous windows doit pouvoir se faire mais nous ne savons pas très bien comment.
Un autre bootloader qui reçoit directement des fichiers HEX
modifierVoici comment Juergen Sauermann, le concepteur de l'ATMega8 a conçu son propre bootloader. Il a décidé de ne pas modifier le cœur pour ne pas faire de saut (matériel) en mémoire programme au moment du reset.
Notre cœur est forcément particulier par rapport au même composant du commerce : il n'a pas de fusibles par exemple.
Ce que Juergan a tenté de faire est un peu différent de la théorie présentée dans la section précédente à cause de l'absence de fusible. Une autre raison est que dans notre coreATMega8, nous ne sommes pas limité par l'instruction SPM contrairement à ce qui se passe dans l'ATMega8 (où elle fonctionne seulement lorsqu'elle est exécutée dans certaines zones de la mémoire programme).
Nous voyons poindre quelques différences avec la théorie de tout à l’heure, comme montrées en figure ci-contre :
- le bootloader à gauche commence à l'adresse 0 par sa table de vecteurs d'interruption (en bleu clair)
- sa partie donnée en mémoire programme (en gris) est gonflée artificiellement pour laisser de la place au futur programme (une autre façon de présenter les choses est de dire qu'un bootloader est petit en principe, mais que le notre est énorme !)
- le programme commence lui aussi en adresse 0
- l'écriture du programme en mémoire détruit la table de vecteur d'interruptions du bootloader et donc en particulier son vecteur RESET (partie droite de la figure où l’on montre les deux superposés)
- en conséquence, il nous faut trouver un mécanisme pour que le programme soit capable d'appeler le bootloader car la figure de droite montre clairement que le bootloader n'a plus de point d'entrée après son écrasement par le programme : comment se brancher au programme bleu turquoise en fin de mémoire qui représente le bootloader ?
Une autre différence qui n'apparait pas sur le dessin est que nous enverrons par la RS232 des fichiers en format HEX (Intel) et non pas en binaire comme cela se fait traditionnellement. La raison est simple, il est plus facile d'opérer quelques vérifications sur un tel fichier, en particulier de tester si l’on est bien arrivé à la fin (du fichier), de tester s'il y a eu une erreur de transmission dans chacune des lignes... et puis on est prêt à utiliser quelques lignes de code supplémentaires pour notre bootloader en lui demandant de déchiffrer un fichier hex : si l’on manque de place on ira en chercher dans le FPGA.
|
|
Le bootloader donné dans la boîte déroulante ci-dessous ne fonctionne pas encore correctement pour le moment mais Juergen Sauermann nous affirme l'avoir fait fonctionner. Il est donc en cours de modification jusqu'à ce que cette bannière disparaisse. |
// fichier intel_hex.c par Juergen Sauermann
#include "stdint.h"
#include "avr/io.h"
#include "avr/pgmspace.h"
#include "uart.h"
#include "build_date"
#define RESTART ((void (*)())0)();
//---------------------------------------------------------------------------
inline void pgm_write_byte(uint16_t addr, uint8_t value)
{
__asm__ volatile (
"push r0" "\n\t"
"push r30" "\n\t"
"push r31" "\n\t"
"movw r30, %0" "\n\t"
"mov r0, %1" "\n\t"
"spm" "\n\t"
"pop r31" "\n\t"
"pop r30" "\n\t"
"pop r0" "\n\t"
:: "w" (addr), "r" (value)
);
}
//---------------------------------------------------------------------------
static void whex1(uint8_t x)
{
if (x <= 9) x += '0';
else x += 'A' - 10;
uart_putc(x);
}
//---------------------------------------------------------------------------
static void whex2(uint8_t x)
{
whex1(x >> 4);
whex1(x & 0x0F);
}
//---------------------------------------------------------------------------
uint8_t hex_error;
static uint8_t hex1()
{
uint8_t cc;
while (!(UCSRA & (1 << RXC))) ;
cc = UDR & 0x7F;
if (cc < '0') ;
else if (cc <= '9') return cc - '0';
else if (cc < 'A') ;
else if (cc <= 'F') return cc - ('A' - 10);
hex_error++;
/* old
hex_error = 1;
uart_puts(" hex1() got ");
whex2(cc);
uart_puts("\r\n"); */
return 0;
}
//---------------------------------------------------------------------------
static uint8_t hex2()
{
const uint8_t h = hex1();
const uint8_t l = hex1();
return h << 4 | l;
}
//---------------------------------------------------------------------------
static void dump_line(uint16_t addr)
{
uint8_t i;
whex2(addr >> 8);
whex2(addr);
uart_putc(':');
for (i = 0; i < 16; i++)
{
const uint8_t d = pgm_read_byte(addr + i);
uart_putc(' ');
whex2(d);
}
uart_putc(' ');
for (i = 0; i < 16; ++i)
{
uint8_t d = pgm_read_byte(addr + i);
if (d < ' ') d = '.';
if (d > '~') d = '.';
uart_putc(d);
}
uart_puts("\r\n");
}
//---------------------------------------------------------------------------
static void dump()
{
uint16_t addr;
uart_puts("Memory:\r\n");
for (addr = 0; addr < 0xA00; addr += 16) dump_line(addr);
}
//---------------------------------------------------------------------------
int
main(int argc, char * argv[])
{
uint8_t record[30];
uint8_t reclen;
uint8_t addr_l;
uint16_t addr;
uint8_t rectype;
uint8_t csum;
int8_t d,i;
uint16_t startBootloaderl;//,startPrgml;//,startBootloaderh,startPrgmh;
// memorisation du start bootloader
startBootloaderl = pgm_read_byte(0) | (pgm_read_byte(1)<<8);
// startBootloaderh = pgm_read_byte(2) | (pgm_read_byte(3)<<8);
uart_puts("\r\nBootloader reset vector : ");
whex2(startBootloaderl);whex2(startBootloaderl>>8);
uart_puts("\r\nloading hex records...\r\n");
i=hex_error = 0;
do // don't waste time in this loop
{
uint8_t sum;
uint8_t dd;
sum = 0;
while ((uart_getc() & 0x7F) != ':') ;//uart_putc('>'); // vérifie OK
record[0] = reclen = hex2(); sum += reclen;
record[1] = addr = hex2(); sum += addr;
record[2] = addr_l = hex2(); sum += addr_l;
record[3] = rectype = hex2(); sum += rectype;
// writing data on RS232 hangs the communication of course
// uart_puts("\r\nData line :");whex2(reclen);whex2(addr_l);whex2(addr);whex2(rectype);
// uart_puts("\r\n");
if (!rectype) {
addr = addr << 8 | addr_l;
for (d = 0; d < reclen; ++d)
{
dd = hex2(); sum += dd;
// record[4 + d] = dd;
// pgm_write_byte(addr++, dd); // uncomment this line and it doesn't work !
}
// manque contrôle de checksum ...
/* record[4 + reclen] = */csum = hex2(); sum += csum;
if(sum) { // error !!!!
uart_puts("\r\nChecksum Error !!!\r\n"); // we give up and then we have time
rectype = 0xFF; // we never loop again !
}
// uart_getc(); uart_getc(); // OxD 0XA end of line
i++;
} //if !rec_type
} while (rectype==0); // we never read last line of HEX file
if (rectype == 1) {
uart_puts("\r\nDone...\r\n");
// RESTART // works here
} else { // retype = 0xFF here !!!
uart_puts("\r\nNumber of lines : ");whex2(i);
uart_puts("\r\nDone... with "); whex2(hex_error); uart_puts(" HEX errors !!\r\n");
pgm_write_byte(0, startBootloaderl);
pgm_write_byte(1, startBootloaderl>>8);
uart_puts("\r\nPlease reset the bootloader !!!\r\n");
// RESTART
}
return 0;
}
//---------------------------------------------------------------------------
const char *
dummy()
{
#define R_0002 "\x00\x00"
#define R_0004 "\x0C\x94\x00\x00"
#define R_0008 R_0004 R_0004
#define R_0010 R_0008 R_0008
#define R_0020 R_0010 R_0010
#define R_0040 R_0020 R_0020
#define R_0080 R_0040 R_0040
#define R_0100 R_0080 R_0080
#define R_0200 R_0100 R_0100
#define R_0400 R_0200 R_0200
#define R_0800 R_0400 R_0400
#define R_1000 R_0800 R_0800
#define R_2000 R_1000 R_1000
#define R_4000 R_2000 R_2000
#define R_8000 R_4000 R_4000
return PSTR(//R_4000
// R_2000
// R_1000 //ne fonctionne plus pourquoi ?
R_0800 //OK seul ou avec R_0100
// R_0400
// R_0200
// R_0100
// R_0080
R_0040
// R_0020
R_0010
// R_0008
// R_0004
// R_0002
);
return 0;
}
//---------------------------------------------------------------------------
Ce fichier doit être complété par :
// Fichier uart.c par Juergen Sauermann
#include "stdint.h"
#include "avr/io.h"
#include "avr/pgmspace.h"
#include "uart.h"
//-----------------------------------------------------------------------------
uint8_t uart_getc()
{
while (!(UCSRA & (1 << RXC))) ;
return UDR;
}
//-----------------------------------------------------------------------------
uint8_t uart_putc(uint8_t cc)
{
// if (PINB & 0x40) return 1; // if simulation.
while ((UCSRA & (1 << UDRE)) == 0) ;
UDR = cc;
return 1;
}
//-----------------------------------------------------------------------------
uint16_t uart_puts_P(const char * s)
{
const char * from = s;
uint8_t cc;
while ((cc = pgm_read_byte(s++))) uart_putc(cc);
return s - from - 1;
}
//-----------------------------------------------------------------------------
static void uart_whex1(uint8_t x)
{
if (x <= 9) x += '0';
else x += 'A' - 10;
uart_putc(x);
}
//-----------------------------------------------------------------------------
void uart_whex4(uint16_t x)
{
uart_whex2(x >> 8);
uart_whex2(x);
}
//-----------------------------------------------------------------------------
void uart_whex2(uint8_t x)
{
uart_whex1(x >> 4);
uart_whex1(x & 0x0F);
}
//-----------------------------------------------------------------------------
et son fichier d'entête associé :
// Fichier uart.h
#ifndef UART_H_
#define UART_H_
#include <stdint.h>
extern uint8_t uart_getc();
extern uint8_t uart_putc(uint8_t cc);
extern void uart_whex2(uint8_t x);
extern void uart_whex4(uint16_t x);
extern uint16_t uart_puts_P(const char * s);
#define uart_puts(x) uart_puts_P(PSTR(x))
//-------------------------------------------------------------
enum KeyboardState
{
// intermediate states (partial ESC sequences)
//
K0_ = 0x00, // nothing
K1_ESC = 0x01, // ESC
K2_ESC_SQ = 0x02, // ESC [
K2_ESC_O = 0x03, // ESC O
K3_ESC_SQ_1 = 0x04, // ESC [ 1
K3_ESC_SQ_5 = 0x05, // ESC [ 5
K3_ESC_SQ_6 = 0x06, // ESC [ 6
// final states (complete ESC sequences)
//
KX_LEFT = 0x81, // ESC [ D
KX_RIGHT = 0x82, // ESC [ C
KX_UP = 0x83, // ESC [ A
KX_DOWN = 0x84, // ESC [ B
KX_PGUP = 0x85, // ESC [ 5 ~
KX_PGDOWN = 0x86, // ESC [ 6 ~
KX_HOME = 0x87, // ESC [ H or ESC [ 1 ~
KX_END = 0x88, // ESC [ F or ESC O F
};
//-------------------------------------------------------------
#endif /* UART_H_ */
Nous ne tenterons certainement pas de faire fonctionner ce bootloader sauf si nous n'arrivons pas à faire fonctionner celui de l'Arduino.
Adaptation au coreATMega8 de l'interface ISP
modifierComme toute interface, sa connaissance fine nécessite de connaître les deux parties qui échangent leurs informations :
- partie logicielle qui tourne sur le PC
- partie matérielle qui reçoit les données
La partie logicielle existe sous de nombreuses formes (AVRStudio, AVRDude, ...) nous n'aurons donc pas à la créer. La partie matérielle par contre est entièrement à réaliser : comment faire croire à AVRStudio ou AVRDude qu’il discute bien avec une interface ISP connectée à un ATMega8 ?
Il n'y a très peu de chances que la réponse à cette question soit documentée quelque part ! Pour y répondre il nous faudra certainement lire les codes sources d'un programmateur ! Ceci est remis à plus tard pour le moment.
Finalement l'écriture du chapitre Arduino dans un autre projet, et le fait que notre enseignement va se faire à partir de 2013 avec Arduino (plutôt qu'avec les PIC16F) nous a amené à nous intéresser particulièrement à cet Arduino. Nous avons découvert qu'un exemple permet de programmer en ISP un autre processeur AVR. Cherchez ArduinoISP dans le répertoire "examples" de votre installation ARDUINO (sous Ubuntu "/usr/share/doc/arduino-core/examples/ArduinoISP"). Cet exemple qui transforme donc un Arduino en programmateur ISP et vous montrera le protocole de liaison STK500v1 d'un côté, et très partiellement le protocole ISP (car utilise l'interface ISP de l'AVR et il faudra donc lire sa documentation pour tout comprendre). Ce code étant relativement compact nous partirons de celui-ci plutôt que de décortiquer le code d'avrdude par exemple.
Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?Voir aussi
modifierProgrammation des mémoires chez Altera
modifierLa gestion des mémoires par Altera est extrêmement différente de celles de Xilinx. Il n'y a pas, à priori, d'équivalent direct à l'utilitaire data2mem. Nous avons utilisé le mot direct qui signifie ici, un utilitaire unique. On verra que deux utilitaires peuvent faire le job.
Les mémoires sont gérées avec les conventions LPM (library of parameterized modules). Pour la petite histoire, Xilinx était signataire de la norme LPM mais ne l'a jamais vraiment proposé dans ses packages... alors qu'Altera l'a toujours fait.
Voici un exemple qui utilise une RAM "lpm_ram_dq" :
LIBRARY lpm;
USE lpm.lpm_components.ALL;
--******** lignes supprimées ******
ma_ram : lpm_ram_dq
GENERIC MAP(LPM_WIDTH => 8,
--- LPM_TYPE: STRING := L_RAM_DQ,
LPM_WIDTHAD => 10,
--LPM_NUMWORDS: STRING := UNUSED,
LPM_FILE => "ma_ram.mif"
--LPM_INDATA: STRING := REGISTERED;
--LPM_ADDRESS_CONTROL => "UNREGISTERED",
--LPM_OUTDATA => "UNREGISTERED"
)
port map (
data=>"11111111" ,
address(9 downto 3)=> "0000000",
address(2 downto 0) => switch,
inclock=>clk,
outclock=>clk,
we =>'0',
q=> s_color_led
);
--********* et plein d'autres choses encore
Le point essentiel est de remarquer que l’on a associé une mémoire à un fichier "ma_ram.mif" qui donne le contenu de la mémoire. A priori deux formats de fichiers sont possibles :
- MIF (Memory Initiation File)
- HEX bien connu des programmeurs de microcontroleurs
Le problème est, que par défaut, le changement du fichier MIF ou HEX du projet suivi d'une recompilation recompile l’ensemble du projet, ce qui prend un certain temps.
Il nous faut donc trouver des solutions pour contourner cela.
Dans l'environnement intégré Quartus
modifierPour la mise à jour du contenu de la mémoire seulement, sans passer par un temps de recompilation complet de l’application (donc plus ou moins équivalent à data2mem), il faut valider l'option "use smart compilation". Pour y accéder : menu assignements => settings => compilation process settings => puis cocher l'option . ne pas oublier de faire "apply" avant de quitter la fenêtre !
Ainsi, changer son fichier .mif et lancer une compilation classique qui devrait être plus rapide (environ 18 secondes là où on avait 1 min 15 s pour un premier essai sans processeur)
En ligne de commande
modifierSi testvga est un nom de projet, on peut mettre à jour les mémoires par les deux commandes :
/opt/altera/15.0/quartus/bin/quartus_cdb --update_mif testvga /opt/altera/15.0/quartus/bin/quartus_asm testvga
Il ne vous reste alors plus qu’à utiliser USBBLASTER pour programmer votre FPGA.
Nous n'avons jamais réussi à faire fonctionner les deux commandes ci-dessus.
Projet CQPIC (PIC 16F)
modifierUtiliser data2mem avec CQPIC
modifierLe projet CQPIC est traité dans le chapitre Embarquer un PIC 16F84.
Comme les sections précédentes le montrent il nous faut un fichier au format elf pour travailler avec data2mem. Ainsi il nous faudra changer de compilateur. Dans cette section, nous allons donc travailler avec SDCC un compilateur libre qui supporte maintenant les PICs 16Fxxx (voir Bico64 pour un exemple utilisant sdcc).
Utiliser sdcc est une mauvaise piste
modifierPour le moment voir premiers pas avec sdcc.
Une lecture de la documentation de sdcc nous a appris que le format objet utilisé par sdcc n’est pas ELF (Executable and Linking Format) mais (en) COFF (Common Object File Format) ! L'utilitaire data2mem n’est pas capable de gérer le format COFF. Il peut cependant gérer le format mem qui doit être aisé à réaliser à partir d'un fichier HEX. Ce problème est en fait résolu en section suivante.
Utilisation générale de data2mem
modifierNous venons de découvrir en lisant (en) Using the AX8 (AVR clone) FPGA core from opencores qu'un utilitaire convertit un fichier hex (Intel) en fichier mem. Visitez la page (en) SRecord 1.60 Files for Download pour le télécharger.
Il est possible d’utiliser simplement data2mem (utilitaire Xilinx) avec toute chaine de développement puisque nous savons passer d'un fichier hex à un fichier mem :
srec_cat pgm.hex -Intel -Byte_Swap 2 -o pgm.mem -vmem 8
Chercher la documentation pour adapter les options.
Utiliser le JTAG pour programmer
modifier Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?Liens externes
modifierDéboguer un programme dans un soft processeur
modifierLa difficulté pour déboguer un programme dans un soft processeur est qu'en général la technique classique consistant à ajouter des "printf" ne fonctionne plus car, en général, vous ne disposez plus d'un écran. Il est facile cependant de remplacer un écran par un hyperterminal car cette façon de faire ne nécessite qu'une liaison série. Faire fonctionner une liaison série est en général relativement facile dans un FPGA.
Déboguer un programme avec le cœur ATMega8
modifierNous avons déjà eu l’occasion de signaler que ce cœur possède une liaison série en standard qui fonctionne à 38400 bauds. Elle a été utilisée par exemple dans le projet Pong et téléphone portable. Nous rappelons ici cependant les fonctions C de base pour communiquer par cette liaison et décrirons plus tard des exemples d'utilisation.
//************************************************************************
// function uart_init()
// purpose: put character in first rs232 PORT
// arguments:
// corresponding character
// return:
// note: 38400,8,n,2 hard coded : transmission and reception
//************************************************************************
void usart_init(void) {
UCSRB = (1<<TXEN)|((1<<RXEN)); // transmission et reception
}
//************************************************************************
// function uart_send()
// purpose: put character in first rs232 PORT
// arguments:
// corresponding character
// return:
// note: 38400,8,n,2 hard coded
//************************************************************************
void usart_send(unsigned char ch){
while(!(UCSRA & (1<<UDRE)));
UDR = ch;
}
//************************************************************************
// function uart_receive()
// purpose: read character in second rs232 PORT
// arguments:
// corresponding character
// return: non-blocking sub return 0 if no data present else return char
// note: 38400,8,n,2 hard coded, non-blocking sub return 0 if no data present
//************************************************************************
char usart_receive(void){
if (UCSRA & (1<<RXC)) //si Data Present en réception
return UDR
else return 0;
}
Une version bloquante de "usart-receive" peut facilement être réalisée à partir de ce code. Cette version ne retournerait plus 0 s'il n'y a rien de reçu mais attendrait tout simplement que quelque chose arrive !
//************************************************************************
// function uart_receive()
// purpose: read character in second rs232 PORT
// arguments:
// corresponding character
// return: blocking sub return char
// note: 38400,8,n,2 hard coded, non-blocking sub return 0 if no data present
// initialisation uart prealable requise
//************************************************************************
char usart_receive(void){
while (!(UCSRA & (1<<RXC))); //attente tant que Data Present en réception
return UDR;
}
Ces fonctions de bases permettent de construire des fonctions un peu plus évoluées comme :
//************************************************************************
// function usart_gets()
// purpose: gets characters in rs232 PORT
// arguments:
// corresponding string where characters are put
// note: 38400,8,n,2 hard coded : transmission
// initialisation uart prealable requise
//************************************************************************
void usart_gets(char str[]) {
uint8_t i=0;
do {
str[i]=usart_receive();
i++;
} while(str[i-1]!=0x0D); // carriage return ?
str[i-1]=0;//end of string
}
//************************************************************************
// function usart_puts()
// purpose: puts characters in first rs232 PORT
// arguments:
// corresponding string (with O as last character)
// return:
// note: 38400,8,n,2 hard coded : transmission
// initialisation uart prealable requise
//************************************************************************
void usart_puts(char str[]){
uint8_t i=0;
do {
usart_send(str[i]);
i++;
} while(str[i]!=0);
}
//************************************************************************
// function usart_puts_hexa()
// purpose: puts number in hexadecimel in first rs232 PORT
// arguments:
// corresponding number
// return:
// note: 38400,8,n,2 hard coded : transmission
// initialisation uart prealable requise
// only for 16-bit numbers and then Q3.13 numbers
//************************************************************************
void usart_puts_hexa(int nbQ3_13){
int8_t i=0,digit=0;
char char_digit;
usart_send('0');usart_send('X');
for (i=12;i>-1;i-=4) {// only four digits
digit = (nbQ3_13 >> i) & 0x0F;
char_digit=digit+0x30;
if (char_digit>0x39) char_digit += 7;
usart_send(char_digit);
}
}
Utiliser un débogueur pour faire du pas à pas
modifierLes "printf" de la section précédente sont faciles à mettre en œuvre mais ne permettent pas de réaliser du pas à pas. Pour cela, il faut dialoguer avec un débogueur et c’est ce problème que nous désirons évoquer dans cette section.
Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?Voir aussi
modifierVous pouvez lire l’article de James W. Grenning dans Dr.Dobb's (Juillet 2013) ainsi que la librairie C associée : Unity.
Déboguer matériellement un soft processeur
modifierDéboguer un soft processeur est particulièrement délicat s'il ne possède pas son interface JTAG correspondante. C'est, dans ce cas précis, à vous de trouver des techniques de mise au point.
À la différence de ce qui a été examiné dans la partie sur la mise au point du logiciel, nous allons traiter dans cette section de la mise au point nécessitant l'ajout d'une partie matérielle.
Mise au point du bootloader dans l'ATMega8
modifierLors de nos essais de mise au point du bootloader Arduino dans notre cœur, nous nous sommes trouvés confronté à un problème qui nous a été difficile de classer : matériel ou logiciel ? À ce jour le problème n’est pas résolu mais nous avons décidé de sortir le compteur programme et de ralentir fortement l'horloge (division par 2^23) et nous présentons ce travail qui pourra certainement servir dans un autre contexte.
Pour votre information, nous avons toujours utilisé le compteur programme affiché sur des afficheurs sept segments pour nous rendre compte si le cœur fonctionnait ou pas. Ceci nous semble donc une technique à conseiller.
Sortir le compteur programme pour deboguer
modifierPour résoudre nos problèmes nous avons été amené à ralentir très fortement le cœur et sortir le compteur programme. Ceci se fait très rapidement avec le cœur dont nous disposons :
- modifier l'entité de notre cœur ATMega8 :
-- Carte utilisée : Nexys 3 (horloge à {{unité|100|MHz}})
entity atmega8 is
port ( I_CLK_100 : in std_logic; -- instead of I_CLK_50
I_PINB : in std_logic_vector(7 downto 0);
I_RX : in std_logic;
I_CLR : in std_logic;
Q_PORTD : out std_logic_vector(7 downto 0); --digit selection
Q_PORTB : out std_logic_vector(7 downto 0);
Q_PORTC : out std_logic_vector(7 downto 0);
--> added 2014/07/25 allows a PC debugging
Q_PC : out std_logic_vector(15 downto 0);
--<
Q_TX : out std_logic);
end atmega8;
où vous voyez apparaître Q_PC sur 16 bits qui est le compteur programme.
- relier cette nouvelle sortie au compteur programme. Cela se fait dans l'architecture correspondante dans le câblage du composant CPU_core où Q_PC qui était relié à open est maintenant à relier à Q_PC
- enfouir cet ancien composant dans un nouveau qui permet le ralentissement et l’affichage du compteur programme sur les quatre afficheurs de la carte.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity debugatmega8 is
port ( I_CLK_100 : in std_logic; -- instead of I_CLK_50
I_CLR : in std_logic;
Q_7segs : out std_logic_vector(6 downto 0);
Q_an : out std_logic_vector(3 downto 0)
);
end debugatmega8;
architecture adebug of debugatmega8 is
component atmega8 is
port ( I_CLK_100 : in std_logic; -- instead of I_CLK_50
I_PINB : in std_logic_vector(7 downto 0);
I_RX : in std_logic;
I_CLR : in std_logic;
Q_PORTD : out std_logic_vector(7 downto 0); --digit selection
Q_PORTB : out std_logic_vector(7 downto 0);
Q_PORTC : out std_logic_vector(7 downto 0);
Q_PC : out std_logic_vector(15 downto 0);
Q_TX : out std_logic);
end component;
signal cmpt : std_logic_vector(23 downto 0);
signal S_PC : std_logic_vector(15 downto 0);
signal hexa : std_logic_vector(3 downto 0);
signal sele : std_logic_vector(3 downto 0);
begin
process (I_CLK_100) begin
if rising_edge(I_CLK_100) then
cmpt <= cmpt + 1;
end if;
end process;
ic:atmega8 port map(
I_CLK_100 => cmpt(23),
I_CLR => I_CLR,
I_RX => '0',
I_PINB => "00000000",
Q_PC => S_PC
);
with hexa select
Q_7SEGS <= "0000001" when "0000",
"1001111" when "0001",
"0010010" when "0010",
"0000110" when "0011",
"1001100" when X"4",
"0100100" when X"5",
"0100000" when X"6",
"0001111" when X"7",
"0000000" when X"8",
"0000100" when X"9",
"0001000" when X"A",
"1100000" when X"B",
"0110001" when X"C",
"1000010" when X"D",
"0110000" when X"E",
"0111000" when others; --X"F"
process (cmpt(15)) begin
if I_CLR = '1' then
sele <= "1110";
elsif rising_edge(cmpt(15)) then
sele(3) <= sele(2);
sele(2) <= sele(1);
sele(1) <= sele(0);
sele(0) <= sele(3);
end if;
end process;
with sele select
hexa <= S_PC(3 downto 0) when "1110",
S_PC(7 downto 4) when "1101",
S_PC(11 downto 8) when "1011",
S_PC(15 downto 12) when others;
-- allways
Q_an <= sele;
end adebug;
Cette technique nous a permis de trouver que :
- le RESET matériel à l'adresse 0x1C00(0x0E00) pour l'Arduino fonctionne correctement (alors que c’est la première chose que nous avons suspecté)
- que c’est data2mem qui n’est pas capable de mettre le programme bootloader en adresse 0x1C00(0x0E00)
Pas mal non pour un si petit bout de programme !
Plus loin encore
modifierEssayer de mettre en œuvre l'interface debug de chez Opencore qui semble bien documentée.
Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?Voir aussi
modifier- La documentation de l'ISP s’appelle "doc0943.pdf" chez ATMEL.
- Cherchez le fichier "bootloader_faq.pdf" qui donne beaucoup de données techniques sur les bootloader AVR.
- Instruction SPM (Atmel)
- AVR106: C functions for reading and writing to Flash memory
- AVR109: Self Programming
- Cherchez ArduinoISP dans le répertoire examples de votre installation ARDUINO (sous Ubuntu "/usr/share/doc/arduino-core/examples/ArduinoISP"). Cet exemple qui transforme un Arduino en programmateur ISP vous montrera le protocole de liaison STK500v1. Rappelons pour être complet que l'environnement Arduino utilise "avrdude" pour programmer.
- AVR JTAG clone in action
- Initiation à JTAG
- Article de James W. Grenning dans Dr.Dobb's (Juillet 2013) ainsi que la librairie C associée : Unity.
