|
|
Programmation
Le logiciel r8cwrite
Quand j'ai commencé à m'interesser aux R8C, il fallait bien que je
puisse les flasher sous Linux, mais comme je n'avais pas trouvé de
logiciel déjà existant, j'ai donc écris l'outil de téléchargement
r8cwrite :
Il reste quelques détails à améliorer, comme par exemple donner la
possibilité à l'utilisateur d'utiliser le port série de son choix (pour
l'instant c'est figé sur /dev/ttyS0), et donner la possibilité de
passer au programme les fameux 7 identifiants (pour l'instant figés à
0x00 ).
Ceux qui veulent utiliser le programme sur un autre port série, c'est
un peu bourrin mais ça marchera : Ouvrez l'executable r8cwrite avec un
éditeur hexa (hexedit par exemple), et remplacez le 0x30 à l'offset
0x1C25 par 0x31 si vous voulez utiliser le com 2.
En cas de question ou en cas de problème, n'hésitez pas à m'écrire.
Pour ceux qui sont interessé par le fonctionnement du logiciel de
téléchargement, et qui veulent eventuellement ecrire le leur, lisez la
suite :
Le protocole de téléchargement
Les microcontrôleurs R8C se flashent par liaison série, ce qui permet de les programmer "in-situ" (Déja monté sur la carte).
Dans un sens il vaut mieux, puisque ces micros n'existent qu'en CMS ;)
Pour pouvoir programmer un R8C, il faut le placer en mode boot et parler avec lui en respectant un protocole. Pour
le mettre en mode boot, il faut forcer la broche "Mode" au niveau 0, et démarrer le R8C
(en mettant sous tension ou en faisant un Reset).
A noter que lors de la programmation, le R8C nécessite une horloge externe.
Donc si sur votre carte vous avez prévu de fonctionner avec
l'oscillateur interne, il vous faudra au moins envoyer un signal
d'horloge sur la broche "XIN" lors de la programmation.
Dans un 1er temps, il va falloir établir une synchronisation avec le
R8C, car il ne connait pas la fréquence d'horloge, donc il ne sait pas
comment régler le baudrate de sa liaison série.
Pour se synchroniser, il faut envoyer à 9600 bauds au minimum 16 fois
la valeur 0x00, avec une pause de 50ms entre chaque octet. Le R8C
analyse ce qu'il recoit, et peut alors configurer les registres
internes de son uart pour pouvoir causer à 9600 bauds.
Après cela, il faut lui envoyer 0xB0 (toujours à 9600 bauds). Si la
synchronisation est faite, le R8C va repondre 0xB0. S'il ne repond pas,
c'est qu'il y a une erreur quelque part, ce n'est pas la peine d'aller
plus loin !
Une fois la synchronisation effectuée, on peut communiquer avec le R8C grâce à quelques commandes :
Lecture d'une page (256 octets)
La page de 256 octets à lire est specifiée par l'adresse de poid fort
(A16-A23) et l'adresse de poid moyen (A8-A15). Comme on lit 256 octets
les 8 bits de poid faible sont inutiles.
Envoyer 0xFF, l'octet de poid moyen de l'adresse, l'octet de poid fort de l'adresse.
Le R8C renvoie les données en reponse (256 octets).
Programmation d'une page (256 octets)
La page de 256 octets à écrire est specifiée par l'adresse de poid fort
(A16-A23) et l'adresse de poid moyen (A8-A15). Comme on écrit 256
octets les 8 bits de poid faible sont inutiles.
Envoyer 0x41, l'octet de poid moyen de l'adresse, l'octet de poid fort de l'adresse, et les 256 octets de données.
Le R8C ne renvoie rien, il faut lancer une commande de lecture du status pour verifier si tout est ok.
Note : Il faut forcement 256 octets, donc s'il y a moins de données il faut completer avec des 0xFF par exemple.
Effacement d'un bloc de flash
Envoyer 0x20, l'octet de poid moyen de l'adresse du bloc à effacer,
l'octet de poid fort de l'adresse du bloc à effacer, puis 0xD0.
Le R8C ne renvoie rien, il faut lancer une commande de lecture du status pour verifier si tout est ok.
Note : l'adresse peut être n'importe quelle adresse appartenant à un bloc.
Lecture du status
Envoyer 0x70
Le R8C renvoie 2 octets, le poid faible puis le poid fort du status.
Signification des bits du status :
BIT0, BIT1, BIT2, BIT3 : réservés
BIT4 : status de programmation (1=erreur, 0=ok)
BIT5 : status d'effacement (1=erreur, 0=ok)
BIT6 : réservé
BIT7 : status du boot (1=pret, 0=occupé)
BIT8, BIT9 : réservé
BIT10, BIT11 : status de l'identification (00:Non identifié,
01:Identification incorrecte, 11:Identification OK)
BIT12, BIT13, BIT14, BIT15 : réservés
Note
1 : Il faut utiliser cette commande après chaque commande d'écriture ou
d'effacement de bloc, pour vérifier si tout s'est bien passé.
Note 2 : Avant d'appeler une commande d'effacement de bloc ou d'écriture, il faut effacer le status.
Effacement du status
Envoyer 0x50
Le R8C ne renvoie rien
Identification
Pour avoir accès à toutes les commandes importantes (effacement de
bloc, lecture, écriture...), il faut s'identifier auprès du R8C en lui
envoyant 7 octets d'identification. On doit spécifier dans cette
commande l'adresse en flash ou sont stockés les IDs, et leur nombre.
Ils sont au nombre de 7 et leur adresse est figée à 0xFFDF.
Envoyer 0xF5, 0xDF, 0xFF, 0x00, 0x07, ID1, ID2, ID3, ID4, ID5, ID6, ID7
Le R8C ne renvoie rien, il faut faire une lecture du status pour voir si l'identification est correcte
Note : Quand le R8C est vierge, pas besoin de s'identifier
Lecture de la version du boot
Envoyer 0xFB
Le R8C renvoie 8 octets, c'est en ascii et sur mon R5F21174 ca me donne : VER.1.00
Modification du baudrate
Envoyer 0xB0 pour passer en 9600 bauds. Le R8C repond 0xB0
Envoyer 0xB1 pour passer en 19200 bauds. Le R8C repond 0xB1
Envoyer 0xB2 pour passer en 38400 bauds. Le R8C repond 0xB2
Envoyer 0xB3 pour passer en 57600 bauds. Le R8C repond 0xB3
Envoyer 0xB4 pour passer en 115200 bauds. Le R8C repond 0xB4
Envoyer 0xB5 puis la valeur du diviseur pour spécifier un baudrate maison. Le R8C retourne cette même valeur comme reponse.
Note 1 : Le R8C modifie son baudrate après avoir envoyé la reponse à la commande.
Note 2 : Après avoir changé le baudrate, si la commande suivante ne
fonctionne pas, c'est que le R8C n'a pas réussi à configurer le nouveau
baudrate avec la fréquence d'horloge à sa disposition. Pour être
tranquille, mettez 20Mhz !
Le protocole étant maintenant connu, c'est presque un jeu d'enfant d'écrire un outil de téléchargement !
Celui ci aura simplement à effectuer les taches suivantes :
- Ouvrir le fichier binaire de l'application à télécharger dans le R8C
- Ouvrir le port série, et le configurer à 9600 bauds
- Envoyer au moins seize 0x00, espacés de 50ms
- Envoyer la commande 0xB0
- Attendre le 0xB0 en retour. Si pas de réponse, fin du programme
- Envoyer la commande 0x70 pour récupérer le status, et s'interesser aux 2 bits de l'identification :
- Si une identification est nécessaire, passer en 7
- Si l'identification est incorrecte, fin du programme
- Si l'identification est correcte, passer en 8
- Envoyer la commande 0xF5 pour s'identifier, puis passer en 6
- Envoyer la commande 0xB3 pour passer à 57600 bauds
- Attendre le 0xB3 en retour. Si pas de réponse, fin du programme
- Passer le baudrate du PC à 57600 bauds
- Envoyer la commande 0x50 pour effacer le status
- Envoyer la commande 0x20 pour effacer un bloc de flash
- Envoyer la commande 0x70 pour récupérer le status, et s'interesser au bit du status de l'effacement :
- Si l'effacement à échoué, fin du programme
- Si l'effacement à réussi et qu'il reste des blocs à effacer, passer en 11
- Si l'effacement à réussi et qu'il n'y plus de bloc à effacer, passer en 14
- Envoyer la commande 0x50 pour effacer le status
- Envoyer la commande 0x41 pour programmer 256 octets de données
- Envoyer la commande 0x70 pour récupérer le status, et s'interesser au bit du status de programmation :
- Si la programmation à échoué, fin du programme
- Si la programmation à réussi et qu'il reste des données à programmer, passer en 14
- Si la programmation à réussi et qu'il n'y plus de données à programmer, passer en 17
- Envoyer la commande 0xFF pour lire 256 octets de données et les comparer avec le fichier binaire :
- Si les données sont différentes, fin du programme
- Si les données sont identiques et qu'il en reste à vérifier, passer en 17
- Si les données sont identiques et que tout a été vérifié, passer en 18
- Programmation terminée avec succès
L'étape 17 sert à relire le programme que l'on vient d'envoyer dans le
R8C afin de le comparer à l'original. Cette étape est indispensable
car
le protocole utilisé n'implémente pas de système de vérification de la
validité des trames (checksum ou CRC par exemple). Donc si on a par
exemple un octet qui passe mal lors de la programmation, le programme
risque fort de ne pas fonctionner ! Pire, il peut fonctionner jusqu'au
moment ou le R8C execute le code à l'endroit de l'octet invalide !
|
|
