Club robotique de Sophia-Antipolis

Accueil > POBOTpedia > Programmation > Apprendre à coder > Les micro-contrôleurs > Les micro-contrôleurs sans ta mère > Péter correctement les plombs

Péter correctement les plombs

ou comment configurer les fuse bits de l’ATmega8

samedi 26 novembre 2005, par Eric P.

La théorie

Les micro-contrôleurs ATMEL sont configurables par le biais de fuse bits et de lock bits.

Il s’agit d’informations non volatiles, qu’il est possible de configurer via l’ISP entre autres, et qui définissent un certain nombre de propriétés, comme par exemple :

  • la configuration de l’horloge, entre l’utilisation de l’oscillateur interne, d’un quartz externe, d’une horloge externe,...
  • la manière dont il démarre
  • la possibilité de provoquer le reset on non via la pin /RESET
  • et bien d’autres trucs encore

Comme d’hab, pour en savoir plus, et surtout éviter de faire les frais d’explications approximatives ou fausses que des énergumènes comme moi pourraient vous donner, il convient d’appliquer ici encore l’adage numéro 1 de la profession :

Le datasheet ta Bible sera, et à tes questions réponse il apportera.

Là où ça coince un peu sur le sujet des fuse bits et consorts, c’est que ATMEL utilise dans le document une convention qui peut troubler au début. Un fuse bit est en effet dit programmé quand il a la valeur 0. Cela est dit de la manière suivante en page 24 du datasheet :

For all fuses “1” means unprogrammed while “0” means programmed.

Bon, on aurait pu penser le contraire, mais c’est comme cela.

Le problème est que, si vous utilisez PonyProg par exemple pour les programmer, il représente par des cases à cocher la valeur binaire du bit en mémoire. Si vous faites le raisonnement « case cochée = bit à 1 », et bien vous aurez gagné un ATMEL sauvage, qui souvent ne sera plus utilisable. Car vous l’aurez programmé à l’envers, et en tout cas pas du tout comme vous le souhaitiez. Il existe des techniques pour ramener à la raison de tels mutants, mais c’est tricky, car la plupart du temps, la liaison ISP ne sera plus disponible. Le temps étant de l’argent, si cela devait vous arriver, il est beaucoup plus rentable (y compris pour les nerfs) d’aller dire un petit bonjour à votre fournisseur attitré de composants, vu le prix moyen d’un ATmega de base.

Conclusion, pour traduire la programmation des fuse bits en coche de case PonyProg, inversez les 1 et les 0 des tableaux de la doc.

La pratique

Pour vous aider à y voir plus clair, voici le paramétrage affiché par PonyProg des fuse bits d’un ATmega163 (ils sont affichés dans le deuxième cadre, le premier étant les lock bits).

Comme vous pouvez le constater, l’auteur de PonyProg a pensé à nous rappeler l’interprétation des case à cocher vis à vis de la valeur binaire des bits telle que définie dans le datasheet.

Si on effectue la même lecture des fuse bits avec avrdude, cela donne ce qui suit :

C:\>avrdude -p atmega163 -c stk200 -P lpt1 -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9402



avrdude: safemode is enabled, you will NOT be able to change the fuse bits. Use
-u option to disable
avrdude> read hfuse
>>> read hfuse
0000  07                                                |.               |

avrdude> read lfuse
>>> read lfuse
0000  ca                                                |.               |

avrdude> quit
>>> quit

avrdude: safemode: Fuses OK

avrdude done.  Thank you.


C:\>

On constate bien que les valeurs 0x07 et 0xca, soit en binaire 00000111 et 11001010, correspondent à ce que nous attendions, sachant que les cases grisées représentent des bits non utilisés valant toujours 0.

Au passage : Pour les réfractaires de la ligne de commande, et si (comme moi maintenant) vous ne pouvez plus utiliser PonyProg car votre nouvelle machine n’a plus de port parallèle, et que par conséquent votre bon vieux programmer à 2 sous n’est plus utilisable, il existe une interface graphique pour avrdude qui s’appelle avrdude-gui. Elle a de plus l’avantage de montrer la ligne de commande équivalent, ce qui, vu l’indigence de la documentation d’avrdude n’est pas du luxe.

Le mot de la fin

Pour tout savoir sur les fuse bits de l’ATmega8, rendez-vous page 220 du datasheet.

Portfolio

Vos commentaires

  • Le 4 avril 2010 à 00:30, par ? En réponse à : Péter correctement les plombs

    Je veux protéger le code de mon ATmega328 sur mon Arduino Duemilanove.

    J’ai utilisé PonyProg2000 Version 2.07c, mais je suis incapable de faire quoi que ce soit.

    Voici ce que j’ai fait

    1) j’ai brancher mon Arduino à l’ordinateur avec le cable USB.

    2) Dans PonyProg je suis allé dans le menu Setup->Interface Setup... et j’ai sélectionné Serial et SI Prog API et j’ai choisi le bon port COM.

    3) Ensuite j’ai sélectionné dans le menu Device->AVR micro->ATmega32.

    4) Après j’ai choisi l’option Command->Security and Configuration Bits... pour modifier les valeurs des fusibles de protection.

    5) ensuite il y a une fenêtre qui est affiché et dans la fenêtre c’est écrit Reading Security Bits et le pourcentage reste à 0% pendant environ 5 minutes et après il y a une autre fenêtre qui est afficher et c’est écrit ce message d’erreur "Device missing or unknown device -24".

    Je doit faire quoi pour modifier les valeurs des fusibles de protection avec PonyProg ?

    Dois-je absolument utiliser la méthode avec le port parallèle pour que ça fonctionne ?

    Dans PonyProg il y a pas d’option ATmega328 dans Device->AVR micro.
    Alors J’ai mit l’option ATmega32.

    Merci

    • Le 4 avril 2010 à 12:28, par Eric P. En réponse à : Péter correctement les plombs

      Bonjour,

      Cela fait longtemps que j’ai abandonné PonyProg (en fait depuis que le changement de machine m’a privé du port parallèle), et donc je ne peux pas trop diagnostiquer précisément les codes d’erreur que tu indiques.

      J’utilise depuis avrdude par exemple, ou bien stk500, avec un programmateur ISP MKII Atmel en USB. Cela répond donc à la dernière partie de la question : il n’y a bien entendu aucune restriction à n’utiliser que le port parallèle, sauf si on tient à rester avec PonyProg (et encore que j’ai entendu dire qu’il supporterait aussi les programmateurs USB maintenant, mais je n’ai pas été le vérifier). Si on parle dans cet article, c’est juste qu’à l’époque de sa rédaction je travaillais encore avec l’ancienne machine.

      Pour en venir à tes soucis, les causes de non reconnaissance du device peuvent être assez diverses :
       non alimenté (ben oui, des fois on oublie...)
       pb de câble (inversion de signaux au niveau de l’ISP par exemple)
       pb de fréquence (avec les programmateurs USB)

      Dans ton cas, il semblerait que la connexion avec le MCU ne s’opère pas, car visiblement PonyProg attend un bout de temps avant de laisser tomber.

      Il faut donc arriver à détecter à quel niveau se situe le problème : programmateur, MCU,...

      Fais l’essai de lire les fuse bits ou la flash d’un autre MCU pour tester la première hypothèse. Si cela fonctionne, c’est donc un souci avec le MCU que tu essayes de programmer. Arrives-tu à relire la flash par exemple ? Si j’ai compris tu as déjà réussi à le programmer, et donc la connexion a déjà marché. Essaye de vérifier si cela fonctionne toujours en le reprogrammant.

      Tente le coup avec un autre type de programmateur si tu le peux aussi.

      Désolé de ne pas avoir de réponse magique, mais ce n’est pas facile de savoir à distance ce qui se passe exactement.

      Cordialement

      Eric

    • Le 4 avril 2010 à 16:26, par Eric P. En réponse à : Péter correctement les plombs

      Je viens de relire ton message et me suis rendu compte que j’y avais raté un "petit détail". Si j’ai bien compris, tu utilises la connexion avec le MCU via le câble USB de ton Arduino (je pensais qu’il s’agissait de la programmation "standard" d’un MCU, sans le contexte particulier de l’Arduino).

      Je ne pense pas qu’il soit possible que PonyProg accède au MCU de la sorte, car sauf erreur la liaison USB permet de télécharger le binaire dans la flash via le bootloader Arduino installé dans le MCU. Cet échange étant spécifique à l’Arduino et à son IDE, à mon avis PonyProg (ou tout autre programmateur style avrdude, stk500,...) n’en a aucune connaissance, car ce n’est pas un mécanisme standard.

      A ma connaissance, (mais je ne suis pas du tout spécialiste de l’Arduino) l’accès aux fuse bits et compagnie ne peut se faire qu’au moyen du connecteur ISP de la carte, et dans ce cas avec les outils habituels (programmateur de type AVR ISP, outils avrdude ou similaire,...).

      Ceci peut expliquer les problèmes que tu as rencontrés.

    • Le 5 avril 2010 à 00:22, par ? En réponse à : Péter correctement les plombs

      Merci Eric pour ton aide !

      en fait depuis que le changement de machine m’a privé du port parallèle

      Si tu veux un port parallèle tu peux acheter une carte en PCI Express :
      http://www.lindy.fr/carte-1-port-parallele-ieee-1284-low-profile-pcie/51246.html

      Ou acheter un port parallèle PCI si ta carte mère possède ces vieux ports.
      http://www.grosbill.com/4-selection_grosbill_carte_pci_2_ports_usb_1_port_parallele_-80336-informatique-controleur

      Je vais faire d’autre test mais cette fois sur le connecteur ISP en me basant sur ce tutorial pour créer mon connecteur ISP : http://arduino.cc/en/Hacking/ParallelProgrammer

      Aussi faire mes test avec d’autre logiciel que PonyProg.

      Merci

    • Le 8 avril 2010 à 09:37, par ? En réponse à : Péter correctement les plombs

      En fait, lors de l’acquisition de la nouvelle machine, j’avais aussi acheté et installé une carte PCI qui me redonnait des ports parallèles.

      Mais elle n’a jamais fonctionné avec les outils de programmation, car il semble y avoir une grande diversité de cartes et surtout de drivers, et la manière dont les ports ajoutés apparaissent au niveau système n’est pas uniforme.

      Avec le modèle installé, il était impossible de faire apparaitre le port à l’adresse standard, et de ce fait aucun des outils ne le reconnaissait. Je sais que certains drivers permettent de remapper les adresses, de manière à ce que les ports ajoutés soient vus comme s’ils avaient été intégrés nativement à la carte mère. Mais manque de bol ce n’était pas le cas de ma carte.

      Elle est donc restée dans la machine à prendre la poussière depuis. Je viens d’ailleurs de la re-découvrir lors de la migration Windows->Linux de cette machine : j’ai ouvert la bête pour y installer un nouveau disque, et j’ai vu cette carte en me demandant : mais qu’est-ce que c’est que ce truc ?

      La conclusion de tout cela est qu’on arrive finalement à vivre très bien sans port parallèle ;)

    • Le 14 avril 2010 à 20:22, par ? En réponse à : Péter correctement les plombs

      Bonjour Éric,

      Aurais-tu la réponse à mes 2 questions sur ce Forum ? http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1269252717/15#15

      Mon nom sur ce Forum est demss.

      Merci

    • Le 15 avril 2010 à 14:21, par Eric P. En réponse à : Péter correctement les plombs

      Concernant la première question, je n’en sais rien car je ne pratique pas du tout l’Arduino.

      Pour ce qui est de la deuxième, j’aurais tendance à dire que non. Dans la doc pointé par Julien sur le forum, on ne parle que de la reprogrammation de la flash, mais pas vraiment des lock et fuse bits.

      Mais pourquoi veux-tu faire cela ? Si c’est pour récupérer un MCU verrouillé par erreur, je pense que ça coûte moins cher d’en prendre un neuf que d’investir dans le programmateur capable de programmer en "haute tension". Mais je peux me tromper.

    • Le 15 avril 2010 à 22:48, par ? En réponse à : Péter correctement les plombs

      Bonjour Éric,

      Mon but était de tester si on peut protéger le code d’un programme mit sur la mémoire FLASH de l’ATmega328 contre les pirates.

      Et mon but d’effacer tout la mémoires FLASH et EEPROM est pour pouvoir réutiliser mon ATmega avec un nouveau Bootloader. Car si le code est protégé la seule chose qu’on peut encore faire est effacer complètement le composant.
      Et je veux pas gaspiller un ATmega328.

      Comme c’est dit ici si il ce trompe pas : http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1269252717/0#0

      sérieux, on ne peut pas empêcher la lecture sans bloquer la programmation à tout jamais ????

      Non, la seule chose que l’on peut encore faire c’est effacer complètement le composant. Toute la mémoire est alors vierge comme à la sortie d’usine.

      Merci

    • Le 16 avril 2010 à 12:17, par Julien H. En réponse à : Péter correctement les plombs

      Comme tu le dis "s’il ne se trompe pas". Il suffit de tester pour s’en assurer.

      Au fait, "protéger la mémoire contre les pirates"... de quels pirates parles-tu ? s’ils accèdent à la puce, c’est que tu leur as donné ? Pourquoi ne veux-tu pas qu’ils aient accès au binaire ? S’il y a un enjeu commercial derrière, as-tu bien vérifié que tu n’enfreignais aucune licence ?

      Si tu utilises Arduino, n’oublie pas que : "the C/C++ microcontroller libraries are under the LGPL."

      Donc franchement "gaspille" un ATmega328, tu éviteras de gaspiller du temps.

    Répondre à ce message

  • Le 9 mai 2006 à 18:55, par ? En réponse à : Péter correctement les plombs

    Salut a tous,
    Si ca peut interesser quelqu’un, j’ai deja configurer le ATMEGA8 a 16Mhz avec AVRdude, la procedure est assez simple :
    Demarer=>Executer=>cmd
    Dans la ligne de commande j’ai taper :
    "avrdude -p m8 -c alf -t"

    Puis il nous met automatiquement Avrdude>
    Ici j’ai taper "d lfuse"
    Puis il nous remet Avrdude>
    J’ai alors taper "w lfuse 0 0xEF"

    PS : Ce site est vraiment bien ! J’y vient regulierement

    • Le 10 mai 2006 à 13:51, par Eric P. En réponse à : Péter correctement les plombs

      Merci pour cette procédure de gestion des fuse bits via avrdude.... et pour le compliment concernant notre site 😉

      Eric

    • Le 9 janvier 2010 à 11:11, par BBenj En réponse à : Péter correctement les plombs

      Précision : si vous programmez comme moi le fuse de la pin reset en i/o, il vous faudra aussi un prog // si vous désirez reprogrammer votre µC...
      (enfin d’après ce que j’ai pu lire, je n’ai pas encore pu tester)
      🙁

    • Le 9 janvier 2010 à 17:56, par ? En réponse à : Péter correctement les plombs

      C’est tout à fait exact. Et là on doit commencer à rigoler... ou pas.

      C’est pourquoi il est déconseillé de modifier la fonction de la pin RESET à moins de vraiment savoir ce qu’on fait et d’en assumer les conséquences.

    • Le 9 janvier 2010 à 18:39, par BBenj En réponse à : Péter correctement les plombs

      Ben en fait je testais un programme (pour piloter un LCD) (à l’origine pas pour un atmega8) qui utilisait la pin reset (et bien sur ça ne fonctionnait pas...), donc moi ben j’ai pas trop réfléchi, j’ai regardé dans les fuses et oh ben tient on peut mettre la pin reset en i/o normal ! Donc voila...

      J’ai commencé avec les PIC, voila pourquoi ! Un pic n’a pas de problèmes de ce genre. Mais je préfère largement les Atmel !

      Je vais me faire un prog // juste pour les fuses, avec un pic. Je vais ptet même le faire autonome, comme ça j’aurais juste à brancher et ça me reprogramme les fuses correctement. 🙂

      Ps : par contre après avoir mis la pin reset en i/o, ça marchait du tonnerre 😛

    • Le 10 janvier 2010 à 11:02, par ? En réponse à : Péter correctement les plombs

      Sauf si c’est pour le challenge, j’opterais personnellement pour une autre option que celle de réaliser un programmateur parallèle : acheter un autre µP.

      Compte-tenu de la modicité de la somme et du fait qu’il faudra de toute manière dédier un µP au programmateur, sans parler des autres composants, du PCB,... à moins d’en avoir vraiment besoin par ailleurs, la démarche ne se justifie pas du tout économiquement parlant.

      Sans parler du temps passé. Je n’ai jamais tenté la manip, mais je crois savoir qu’un collègue s’y est frotté et y a laissé pas mal de neurones et d’heures de sommeil. Et pourtant c’est tout sauf un manche en électronique et µP.

      Maintenant, si comme je le disais c’est pour le sport, alors c’est une autre histoire. Dans ce cas, bon courage pour cette entreprise ;) Et tiens-nous au courant.

    • Le 10 janvier 2010 à 11:35, par BBenj En réponse à : Péter correctement les plombs

      Oui ms j’ai pas prévu de passer une commande avt un moment, et je n’ai pas de boutique qui vend des µC dans le coin.
      Le jour où je déménage je m’installe à côté d’un grand magasin d’élec 😄

      Pourtant la doc est très clair sur le sujet, ça n’a pas l’air compliqué !! Même plutôt très simple.
      Et puis il me reste des pic que je n’utilise plus (des 16F84) et que j’avais eu en sample, donc autant les utiliser 🙂

      Si je reviens pas c’est que ça ne marche pas ^^

    Répondre à ce message

  • Le 16 juin 2007 à 23:19, par Julien H. En réponse à : Cité sur un site web

    L’article d’Eric est cité sur la page de silicium628 qui partage notre intérêt pour la famille de microcontrôleurs Atmega

    Répondre à ce message

  • Le 5 août 2006 à 22:55, par ? En réponse à : Péter correctement les plombs

    Bravo pour cet article. J’en ai malheureusement pris connaissance après avoir ( mal ) programmé les fuses de mon chip. Quelle est cette méthode tricky permettant de récupérer la bête ?

    • Le 12 août 2006 à 11:16, par ? En réponse à : Péter correctement les plombs

      Cette méthode tricky est la programmation parallèle. En fait, en paramétrant incorrectement les fuse bits, on peut se retrouver avec le SPI hors service, et donc sans possibilité d’intervenir sur le micro via le câble de programmation habituel.

      La programmation parallèle consiste à envoyer les données en parallèle (comme son nom l’indique) en non pas en série (comme via le SPI). Pour ce faire, on utilise des IOs des ports B et C pour les data, du port D pour la signalisation, ainsi que l’entrée XTAL1 pour la clock. Il y a ensuite un chronogramme précis à respecter pour tous les signaux. Tout cela est décrit en détail dans la bible (euh, pardon, le complete datasheet), en page 223 et suivantes. Bien entendu, cela ne peut pas se faire avec le µC dans son circuit (car les IOs nécessaires sont vraisemblablement câblées), mais requiert d’avoir une platine dédiée à cela et d’y transporter le µC le temps de l’opération (comme à l’ancienne avec les programmateurs hard).

      Bon, ça c’est la théorie. En pratique, c’est tellement ch**nt à mettre en oeuvre (je ne l’ai jamais fait, mais je rapporte les propos de certains de mes collègues qui l’ont essayé) que c’est plus vite fait de jeter le µC et d’en prendre un neuf. Vu le coût de la bête, ça ne vaut pas tous les neurones que tu vas griller (d’autant qu’il n’y a pas de méthode connue pour les récupérer eux 😉)

    Répondre à ce message

Un message, un commentaire ?

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.