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.
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 !
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
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