Bonjour à toutes et à tous !

Comme promis, voici la suite du projet de programmateur de PIC. Nous avons vu la dernière fois une présentation sommaire du programmateur de PIC et de ses fonctionnalités. Aujourd’hui nous allons nous atteler à la première d’entre elles : l’effacement intégral de la mémoire.

Tout d’abord, je vais vous présenter le principe de fonctionnement de l’effacement et de quelques cas d’utilisation. Ensuite, nous allons voir ensemble la constitution du protocole de communication. Enfin, nous verrons par quelle trame ordonner au microcontrôleur l’effacement complet de sa mémoire.

Principe

L’effacement de la mémoire est généralement un pré-requis à l’écriture dans la mémoire. Cela afin de se débarrasser des résidus de programme qui pourrait subsister en se contentant de simplement écrire par-dessus le programme précédent.

Il a également une autre utilité. Le PIC18F2550, entre autres, dispose en effet d’un mécanisme de protection de l’accès à la mémoire. Pour pouvoir réécrire un programme dans une zone mémoire protégée, il faut procéder à l’effacement de la mémoire qui va également réinitialiser les droits d’accès de toutes les zones de mémoire.

Nous ne verrons ici que l’effacement intégral, plus simple à mettre en œuvre.

Chronogrammes et programme

Nous avons vu brièvement dans le précédent article le déroulement de la programmation du microcontrôleur. Je vous propose ici de voir les premières étapes plus en détail.

N.B. : Dans le doute, je préfère ne pas mettre ici les diagrammes présents dans la documentation de Microchip. Toutefois, comme « il est toujours bien plus facile de comprendre avec un dessin », je vous invite à consulter directement le document concerné. Afin de vous faciliter la recherche, j’indiquerai pour chaque diagramme le numéro de la figure et la page.

Entrée en mode Program/Verify

Lors de la programmation du microcontrôleur, la tension d’alimentation se situe entre 3,0V et 5,5V (si le microcontrôleur fonctionne avec son oscillateur interne) ou entre 2,0V et 5,5V (si un oscillateur externe est utilisé) et ce quel que soit le mode d’alimentation utilisé (Low-Voltage ou High-Voltage). De plus, toutes les broches doivent être à l’état bas, sauf V_DD.

• Low-Voltage (page 17, paragraphe 2.6, figure 2-16)

L’entrée dans le mode Program/Verify consiste à indiquer au microcontrôleur que l’on se place en mode Low-Voltage via la broche PGM avant d’alimenter la broche de programmation V_PP avec la tension adéquat (entre 2,0V et 5,5V pour le mode Low-Voltage).

Dès lors, nous commençons par placer la broche PGM à l’état haut. Après un court délai minimum de 2 microsecondes, on peut placer la broche V_PP à l’état haut puis attendre encore 2 microsecondes minimum avant de transmettre des données via les broches PGD (données) et PGC (horloge).

• High-Voltage (page 16, paragraphe 2.5, figure 2-14)

Si on utilise le mode High Voltage, la tension de programmation se situe entre V_DD+4,0V (donc entre 6/7V et 9,5V, selon l’oscillateur utilisé) et 12,5V et la broche PGM n’est pas du tout utilisée. On commence par alimenter le microcontrôleur et attendre un délai minimum de 100 nanosecondes. Avant de placer la broche de tension de programmation à l’état haut.

Important : le temps de montée de la broche V_PP ne doit pas dépasser une microseconde !

Comme pour le mode Low-Voltage, ce n’est que 2 microsecondes après le moment où V_PP atteint l’état haut que l’on peut commencer à transmettre via PGD et PGC.

Une routine pour effectuer cette entrée en « Program/Verify mode », en mode Low-Voltage, ressemblerait à ceci :

/*
 * Enter Program/Verify mode
 */
void enter_program_verify_mode()
{
    digitalWrite(PGM, HIGH);
    delayMicroseconds(2);
    digitalWrite(VPP, HIGH);
    delayMicroseconds(2);
}

Sortie du mode Program/Verify

• Low-Voltage (page 17, paragraphe 2.6, figure 2-17)

Il faut avant tout que les broches PGD et PGC soient et restent à l’état bas, signe qu’elle ne transmettent plus. On peut alors placer V_PP puis PGM à l’état bas. Aucun délai n’est à respecter.

• High-Voltage (page 16, paragraphe 2.5, figure 2-15)

Comme pour le mode Low-Voltage, il faut avant tout que les broches PGD et PGC soient et restent à l’état bas. On peut alors, sans attendre, placer V_PP à l’état bas, tout en respectant un temps de descente d’une microseconde maximum. Puis, dans un délai maximum de 100 nanosecondes, on doit placer V_DD à l’état bas.

Une routine pour effectuer la sortie du « Program/Verify mode », en mode Low-Voltage, ressemblerait à ceci :

/*
 * Exit Program/Verify mode
 * Power is on (VCC and Programming voltage)
 */
void exit_program_verify_mode()
{
    digitalWrite(PGD, LOW);
    digitalWrite(PGC, LOW);
    digitalWrite(VPP, LOW);
    digitalWrite(PGM, LOW);
}

Envoi de trame (page 18-19, paragraphe 2.7, figure 2-18)

Comme je l’ai dit dans l’article précédent, les commandes sont formés de 20 bits : 4 bits pour l’instruction et 16 bits pour le payload. Ici, je vous détaille comment ces commandes sont transmises.

La transmission s’effectuant en Little-Endian, le plus faible des 4 bits est transmis en premier jusqu’à celui le plus fort. On en fait de même avec les 16 bits, en commençant par le plus faible des 16 et en terminant par le plus fort.

Pour chaque bit, l’horloge doit se placer à l’état haut, la broche de données doit se placer ou être déjà placé à l’état haut pour transmettre un 1 et à l’état bas pour transmettre un 0. Enfin, on place l’horloge à l’état bas pour amorcer l’émission du bit.

Une période d’horloge doit durer au minimum 100 nanosecondes, avec un minimum de 40 nanosecondes pour chaque état d’horloge. Ceci est valable lorsque le microcontrôleur est alimenté en 5V. Lorsque V_DD = 2V au lieu de 5V, ce temps minimum doit être décuplé (400 nanosecondes et 1 microseconde au lieu de 40 et 100 nanosecondes).

Concernant la broche de données, il doit s’écouler au moins 15 nanosecondes entre la mise à l’état souhaité et le passage de l’horloge à l’état bas. De même, le temps de maintien de la broche de données à l’état souhaité doit durer au moins 15 nanosecondes à partir du moment où l’horloge est passée à l’état bas.

Enfin, entre la fin de la transmission du dernier des 4 bits de commande et le début de la transmission du premier des 16 bits de payload, il doit s’écouler au minimum 40 nanosecondes. De même à la fin de la transmission du dernier des 16 bits de payload : avant de transmettre quoi que ce soit, il est nécessaire d’attendre au moins 40 nanosecondes.

N.B.: Je sais qu’il peut sembler ridicule d’exiger de patienter durant un temps aussi infime qu’une microseconde ou que quelques nanosecondes. Cependant, à l’échelle du microcontrôleur, ce n’est pas anodin. Si je prends par exemple la fréquence de l’oscillateur interne du PIC18F2550, qui est de 8 MHz, cela nous donne une instruction tous les 500 nanosecondes (T_OSC= 1/f = 1/8000000Hz = 0,000000125 secondes = 125 nanosecondes ; T_CY = T_OSC * 4 = 125 * 4 = 500 nanosecondes par cycle instruction). C’est juste dans la plupart des cas et insuffisant lorsque V_DD est de 2V. Dans notre cas, nous utilisons un Arduino cadencé à 16 MHz et le cycle d’instruction se fait le plus souvent en un ou deux cycles d’horloges au lieu de quatre (une particularité des microcontrôleurs AVR sur lesquels sont basés la plupart des cartes Arduino), ce qui amène le temps de cycle à 62,5 ou 125 nanosecondes.
Dans notre cas, cela devrait suffire, la plupart des délais à respecter n’atteignant pas 62,5 nanosecondes.

Voici à quoi ressemblerait la routine permettant d’envoyer une commande au microcontrôleur.

/*
 * Send a command to the chip
 */
void send_command(char command, char lowbyte, char highbyte)
{
    char i;

    /* Command */
    for (i = 0; i < 4; i++) 
    { 
        digitalWrite(PGC, HIGH); 
        if ((command & 1) == 1) 
        { 
            digitalWrite(PGD, HIGH); 
        } 
        else 
        { 
            digitalWrite(PGD, LOW); 
        } 
        digitalWrite(PGC, LOW); 
        command = command >> 1;
    }

    /* Low Byte */
    for (i = 0; i < 8; i++) 
    { 
        digitalWrite(PGC, HIGH); 
        if ((lowbyte & 1) == 1) 
        { 
            digitalWrite(PGD, HIGH); 
        } 
        else 
        { 
            digitalWrite(PGD, LOW); 
        } 
        digitalWrite(PGC, LOW); 
        lowbyte = lowbyte >> 1;
    }

    /* High Byte */
    for (i = 0; i < 8; i++) 
    { 
        digitalWrite(PGC, HIGH); 
        if ((highbyte & 1) == 1) 
        { 
            digitalWrite(PGD, HIGH); 
        } 
        else 
        { 
            digitalWrite(PGD, LOW); 
        } 
        digitalWrite(PGC, LOW); 
        highbyte = highbyte >> 1;
    }
    digitalWrite(PGC, LOW);
    digitalWrite(PGD, LOW);
}

Les commandes d’effacement

À présent, nous disposons de routines permettant l’envoi de commandes qui respectent les standards imposés par la documentation du composant. Nous pouvons à présent transmettre l’ordre d’effacement.

Mais qu’envoyer ? La documentation nous indique la séquence suivante :

4-Bit Command (binary)	Data Payload (hexadecimal)	Core Instruction (assembly)
0000	0E 3C	MOVLW 3Ch
0000	6E F8	MOVWF TBLPTRU
0000	0E 00	MOVLW 00h
0000	6E F7	MOVWF TBLPTRU
0000	0E 05	MOVLW 05h
0000	6E F6	MOVWF TBLPTRU
1100	3F 3F	Write 3F3Fh to 3C0005h
0000	0E 3C	MOVLW 3Ch
0000	6E F8	MOVWF TBLPTRU
0000	0E 00	MOVLW 00h
0000	6E F7	MOVWF TBLPTRU
0000	0E 04	MOVLW 04h
0000	6E F6	MOVWF TBLPTRU
1100	8F 8F	Write 8F8Fh to 3C0004h
0000	00 00	Hold PGD low until erase completes
0000	00 00

Que nous dit cette séquence ? Tout simplement que l’on cherche à se positionner à l’adresse 0x3C0005 via le pointeur TABLPTR (dont j’ai parlé au précédent article) pour y inscrire la valeur 0x3F puis refaire de même avec la valeur 0x8F à l’adresse 0x3C0004.
On termine l’ordre par un NOP (une instruction assembleur dont le principe est de ne rien faire) pour que démarre l’effacement. Ce dernier se déclenche au front descendant d’horloge du 4ème bit de commande du NOP. Lors de l’opération d’effacement, la liaison série sera indisponible jusqu’à la fin (au moins 5 millisecondes). Pendant ce temps, l’horloge peut continuer à osciller, mais la broche de données doit impérativement rester à l’état bas.
Un délai supplémentaire d’une dizaine de microsecondes au minimum doit être opéré à la fin du temps d’attente avant de reprendre toute communication avec le microcontrôleur.

La documentation n’en dit hélas pas davantage sur ces instructions, hormis qu’aux adresses 3C0005h et 3C0004h se situent deux registres dédiés à l’effacement du microcontrôleur ainsi que les valeurs à utiliser pour ces registres selon les zones de mémoire que l’on souhaite effacer.

Mise en pratique

Après quelques tâtonnements, je suis parvenu à écrire un programme Arduino qui effectue l’effacement du microcontrôleur PIC18F2550 auquel il est relié. Pour m’assurer que l’effacement était bien effectif, le programme se termine par une petite boucle qui fait osciller V_PP. Le programme précédent se contentant uniquement de garder une LED allumée, si la LED restait éteinte à la fin du programme, l’effacement était considéré comme réussi.

ArduinoICSP – Bulk Erase

Bien évidemment, j’ai revérifié après avec un autre programmateur si la mémoire était bien vierge, et ce fut le cas.
Notez également que j’ai choisi la broche 13 pour commander V_PP. Ce n’est pas anodin : cette broche commandant également une LED intégrée à la carte Arduino, cette dernière me fournissait un témoin visuel que la broche était bel et bien en train de changer d’état.

Les broches V_DD et V_SS du PIC18F2550 sont connectées respectivement aux broches V_CC 5V et GND de la carte Arduino.

La commande pour l’effacement se trouve ici n’être qu’un simple tableau qui est transmis par le programme principal en temps qu’arguments à la fonction d’envoi de trame. C’est largement suffisant et les autres opérations seront exécutées de la même manière, avec quelques subtilités cependant (je pense par exemple à l’écriture de programme).

Conclusion

C’est terminé avec l’effacement du microcontrôleur. Il s’agissait d’un article très consistant, ce qui explique pourquoi je ne le publie que maintenant. J’espère parvenir à poursuivre le projet et l’écriture des articles rapportant mes progrès. J’ai moins de temps depuis que j’ai retrouvé un emploi le mois dernier (je ne m’en plains pas, c’est un boulot qui me plaît et les progrès que j’y fais me servent pour ce projet, et réciproquement).

Je m’efforce également de ne pas digresser sur d’autres sujets, ce qui est assez difficile car j’ai déjà plein d’idées de projets que je meurs d’envie de partager ici. Il faudra patienter le temps que je finisse le projet de programmateur de PIC. Les autres qui viendront par la suite seront, je l’espère, plus concis que le programmateur bien que tout aussi intéressants (voire davantage).

Sur ce, je vous laisse et je vous dis à bientôt.

Nicolas SAN AGUSTIN