Protocole de programmation par l'uart : ca marche !

[nlc]

Bonsoir a tous.

J'ai vu sur ce forum que certaines personnes cherchaient le protocole utilisé pour flasher les R8C par l'uart.

Le voici :

Synchronisation avec le R8C :
-----------------------------

- Mettre la patte MODE du R8C a 0
- Faire un reset du uC, le R8C passe en mode boot
- Envoyer 16 0x00 a 9600 bauds. Faire une pause d'au moins 20ms apres chaque envoi
- Envoyer un 0xB0 à 9600 bauds

Si la connexion est etablie, le R8C retourne un 0xB0

On peut ensuite causer avec le R8C grace a plusieurs commandes :



Lecture d'une page (256 octets)
-------------------------------

La page de 256 octets a lire est specifiée par l'adresse de poid fort (A16-A23) et l'adresse de poid moyen (A8-A15).

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 a ecrire est specifiée par l'adresse de poid fort (A16-A23) et l'adresse de poid moyen (A8-A15).

Envoyer 0x41, l'octet de poid moyen de l'adresse, l'octet de poid fort de l'adresse, 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 a effacer, l'octet de poid fort de l'adresse du bloc a 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 etre n'importe quelle adresse appartenant a un bloc


Lecture du status
-----------------

Envoyer 0x70

Le R8C renvoie 2 octets, respectivement le poid faible puis le poid fort du status
Signification des bits du status :
BIT0, BIT1, BIT2, BIT3 : réservé
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, O=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é

Il faut utiliser cette commande apres chaque commande d'ecriture ou d'effacement de bloc, pour voir si tout s'est bien passé.
Mais avant d'appeler une commande d'effacement de bloc ou d'ecriture, il faut effacer le status.


Effacement du status
--------------------

Envoyer 0x50

Le R8C ne renvoie rien


Identification
--------------

Pour avoir acces a toutes les commandes importantes (effacement de bloc, ecriture...), il faut s'identifier aupres du R8C
en lui envoyant 7 octets d'identification. On doit specifier dans cette commande l'adresse en flash ou sont stockés les IDs,
et leur nombre, donc :

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 specifier un baudrate maison. Le R8C retourne la meme valeur comme reponse.

Note : Le R8C modifie son baudrate APRES avoir envoyé la reponse a la commande.





Grace a ces infos, on peut developper son propre logiciel de telechargement R8C (par l'uart). C'etait imperatif pour moi,
car je travaille sous Linux. J'ai donc ecrit un logiciel de telechargement en suivant ce protocole et ca marche niquel.
Je suis les etapes suivantes :

1) Reglage de la com a 9600 bauds
2) Envoi de 16 Ox00
3) Envoi de 0xB0
4) Si pas de 0xB0 recu avant 0.5s, le logiciel sort en erreur : cible non detectée

5) Lecture du status pour verifier si l'identification est bonne, verification des bits 10 et 11 :
00 : Non identifié, passe en 6)
01 : Identification incorrecte, le logiciel sort en erreur : IDs d'identification incorrects
11 : Identification OK, passe en 7 (Quand le R8C est vierge, on est dans ce cas, du coup pas besoin de s'identifier)
6) Envoi de la commande d'identification, et retour en 5)

7) Envoi de 0xB3 (passage en 57600 bauds)
8) Si pas de 0xB3 recu avant 0,5s, le logiciel sort en erreur : timeout dans la connexion
9) Reglage de la com a 57600 bauds

10) Effacement du status (0x50)
11) Effacement d'un bloc flash
12) Lecture du status pour verifier si tous va bien, et retour en 10) tant qu'il reste des blocs a effacer

13) Effacement du status
14) Envoi d'une commande d'ecriture de page
15) Lecture status pour verifier si tous va bien, et retour en 13) tant qu'il reste des données a programmer

On peut ensuite (pour bien faire) faire une relecture et comparer pour voir s'il n'y a pas eu d'erreur de transfert.
C'est meme indispensable car le protocole n'integre aucun checksum !

Bon developpements a tous !

[ymasquel]

Bonjour "nlc",

Excellente contribution. Même si je ne cherchais pas actuellement le protocole de communication du mode "flashage/débug" il s'agit d'une excellente étude que j'aurai probablement l'occasion d'expérimenter (que ce soit sous windows comme sous LINUX dont je suis fervent utilisateur).

Encore bravo pour cet esprit de partage qui met à disposition de chacun une trouvaille. C'est un but essentiel du forum.

Une question :
- est-ce que tu rencontres les mêmes difficultés que beaucoup pour entrer en communication avec la puce ou est-elle détectée et synchronisée sans difficultés - erreur 15024 par ex. ?

Amicalement, Yves.

[r8c13master]

Bonjour nlc

Toutes mes félicitations pour ce post détaillé, bien présenté et surtout très intéressant.

Nul doute qu'il va intéresser de nombreux utilisateurs du R8C.

[nlc]

Une question :
- est-ce que tu rencontres les mêmes difficultés que beaucoup pour entrer en communication avec la puce ou est-elle détectée et synchronisée sans difficultés - erreur 15024 par ex. ?

J'imagine que cette erreur vient du logiciel de programmation que vous utilisez. Pour ma part, comme j'utilise linux, je n'ai pas eu l'occasion de l'essayer, j'ai directement ecris mon propre programme de telechargement. Et ca se synchronise a tous les coup sans aucun probleme. Dès l'instant ou on respecte bien le baudrate, les 16 0x00, le 0xB0, avec une pause d'au moins 20ms entre chaque octet, ca marche a tous les coups. Donc j'imagine que l'erreur est provoquée par le logiciel lui meme qui ne respecte pas certain timing ?

[ymasquel]

Bonjour "nlc",

Ce qui est surprenant c'est qu'il s'agit d'un logiciel fourni par le fabricant du R8C lui-même (même si ce logiciel n'est pas nécessairement une de ses propre création).
Pour déterminer le protocole et les timings je suppose que tu as utilisé un sniffer en parallèle sur l'interface série d'un R8C13 en cours de programmation / déverminage depuis un logiciel fonctionnant sous windows. Si c'est cela peux-tu nous dire quelle était la version de windows utilisée car je soupçonne des comportements variables sur les ports série en fonction des versions.
J'en profite pour poser la même question à tous ceux qui ont eu des problèmes de programmation ou même à ceux qui n'en ont pas eu), quelle est la version de windows qui était utilisée car je n'ai pas souvenir d'avoir eu un problème avec windows98?

Amicalement, Yves.

[nlc]

Non, je ne travaille pas sous windows )
Je nai donc utilisé aucun logiciel windows.

C'est quel logiciel qui vous pose des souci de synchro ? Le "M3A-0806" ?
Dans le source de ce programme on peut trouver les commandes du protocole et les timings.
Les sources sont en telechargement ici : http://eu.renesas.com/fmwk.jsp?cnt=/download_search_results.jsp&fp=/support/downloads/download_results&layerId=1216

Par exemple, dans le fichier M16Cflsh.cpp, a partir de la ligne 260 cest la synchro qui va etre faite.
On voit bien qu'entre chaque octet 0x00 il y une pause de 20ms.

Dans mon programme j'avais mis une pause de 100ms entre chaque octet. J'ai donc essayé avec 20ms, et effectivement ca ne synchronise
pas a tous les coups. Alors en regardant a l'oscillo sur la liaison serie, j'ai vu le pb :
Le programme envoie un 0x00 puis fait une pause de 20ms. Mais le PC n'envoie pas l'octet de suite, il doit etre buffeurisé quelque part.
Ensuite le programme renvoie un autre 0x00 et refait une pause de 20ms. Et là, a l'oscillo, je vois les 2 octets partir d'un seul coup !
Du coup, sur les 16 octets envoyés, on a pas forcement une vraie pause de 20ms entre chaque. Je pense que ca doit etre le meme style de probleme
sous windows.

Mais j'ai remarqué que le nombre de 0x00 n'est pas important, il suffit juste d'en avoir au minimum 16. Du coup maintenant dans mon programme
j'en envoie 50 (et sans aucune pause entre chaque !), et ca synchronise a tous les coups.'

[ymasquel]

Bonjour "nlc",

Bien vu!
Je pense que la plupart des utilisateurs passe par FDT ou KD30 pour communiquer avec le R8C13.
J'avais pourtant téléchargé le source du m3a0806 dans sa version v020046 (maintenant v020046e) mais pas pris le temps de m'y attarder.
Je viens maintenant d'y jeter un coup d'oeil et y ai entrevu les clés de la communication série avec les puces de RENESAS dans leur mode "DEBUG".

Félicitations pour cette découverte.

Amicalement, Yves.

[nlc]

Je viens de tester le telechargement du R8C sans quartz externe, pour voir si le boot du R8C peut tourner sur son oscillateur interne.

Et bien ca ne marche pas
Meme la synchronisation, qui tourne pourtant a 9600 bauds, ne fonctionne pas.

Donc tous ceux qui veulent faire des projets utilisant lhorloge interne et qui veulent programmer le uC avec la liaison serie de leur PC doivent faire une carte d'interface comprenant un oscillateur 4 ou 8Mhz qui sera envoyé vers la pin XIN du uC.

Sur la carte electronique cible, le strict minimum serait donc un petit connecteur 6 points comprenant :
- +5v
- GND
- Mode
- TX
- RX
- XIN

La carte d'interface doit integrer un convertisseur RS232 et un oscillateur 4 ou 8mhz qui envoie le signal vers la broche XIN. La broche Mode peut etre routée a la masse.
Du coup pour programmer le R8C il suffit de brancher la carte d'interface sur la carte cible, et de connecter l'alimentation de la carte (ou faire reset). La carte d'interface force le Mode a 0 et envoie le signal d'horloge, donc le R8C entre bien en mode boot. Le soft PC fait le reste