Connexion de la carte
Lorsque la carte arrive, elle est déjà programmée avec un code de test qui - entre autres - fait clignoter la led verte.
Premier test
Nous allons commencer par lire les fuse bits. Il s’agit d’un petit contrôle de communication qui permet de préserver le programme de démo contenu dans la carte.
On reprend les explications d’Eric sur les fusebits et on les met en pratique.
En préalable il faut vérifier notre installation de avrdude et vérifier qu’on l’a bien configuré pour faire fonctionner le programmateur d’In-Circuit sur USB par émulation d’un port série.
– port : vérifier dans vos périphériques le port assigné
– type de programmateur : avr910
– vitesse : 115200 bauds
On tape la commande et le logiciel passe dans un mode "ligne de commande" où il attend nos ordres.
On demande alors les valeurs des high fuse bits (read hfuse) et des low fuse bits (read lfuse) et on obtient les valeurs.
Sur notre carte neuve, les valeurs sont :
– hfuse : 0xD9 soit 0b 1101 1001
– lfuse : 0xEF soit 0b 1110 1111
En lisant la datasheet, on regarde quels bits sont programmés (ie. ils ont la valeur 0) et on comprend que :
– h6 à 1 : pas de watch-dog
– h5 à 0 : on est en mode ISP (programmation série via ISP)
– l0..3 à 1 : clock externe
Lisez la doc pour le reste (start-up time, brown-out, ..)
Maintenant, utilisons ces nouvelles connaissances pour résoudre un de nos problèmes : nos anciennes cartes ICmega rebootent tout le temps ! Regardons leurs fuses bits :
Sur notre carte "plantée", les valeurs sont :
– hfuse : 0x99 soit 0b 1001 1001
– lfuse : 0xC1 soit 0b 1100 0001
Argh ! regardez la patte 6 du high fuse byte : elle est à 0, ce qui signifie que le watchdog est armé... d’où nos problèmes (je jure avoir lu la datasheet avant de dire que ça ne venait pas du watchdog, et pourtant...)
Maintenant, le low fuse byte : c’est pas comme sur la configuration d’origine, puisque le "start-up time" est à 00 au lieu de 10, ce qui signifie qu’on ne laisse pas de délai au reset ce qui correspondrait à l’utilisation du brown-out (ce que les fuse bits du brown-out contredisent : 11 sur les pins 6 et 7 du low fuse byte). Que faire ? La question est posée parce que mes connaissances sont limitées, je vais lire le bouquin de Christian Tavernier (Dunod), ça me fera le plus grand bien.
Voici l’explication d’Eric, qui connait mieux la datasheet que moi : En fait, il n’y a aucun rapport entre le start-up time et le brown-out detector. Le rôle du BOD (lorsqu’il est activé) est de déclencher un reset lorsque le µC détecte que la tension d’alimentation passe sous un certain seuil, ou de ne lâcher le reset que si la tension est au-dessus de ce seuil. Dans la configuration constatée, si le BOD avait été activé en mettant le bit 6 du low fuse byte à 0, le seuil aurait été configuré à 2.7V (il aurait été à 4V si BODLEVEL avait valu 0 - cf p38 du datasheet complet de l’ATmega8).
Maintenant concernant le start-up time, il s’agit de retarder le moment où on lâche les chevaux par rapport à la mise sous-tension. En fonction de la nature de l’alimentation et du temps d’établissement et de stabilisation de la tension, on peut vouloir allonger ce délai au moyen des fuse bits SUT0..1. "00" correspond au délai le plus court, puisqu’on n’ajoute aucun délai supplémentaire aux 6 clocks incompressibles que prend le démarrage du moteur. On peut utiliser cette configuration si on sait que la tension d’alimentation s’établit suffisamment vite. Tout cela est complètement indépendant du BOD. Le tableau de la page 30 suggère seulement (cf le titre de la colonne : "Recommended usage") d’utiliser cette configuration lorsque le BOD est activé, puisque dans ce cas, il va surveiller la tension et donc ne lâcher les fauves que si elle est suffisante, si d’aventure les Shadocks préposés à la génératrice ne faisaient pas correctement leur boulot. Mais cela ne veut pas dire que la valeur 00 active le BOD ou n’est utilisée que s’il est activé. Si on est sûr du coup, on peut y aller. C’est vrai que 01 serait plus prudent, puisqu’on ajoute 4ms pour s’assurer que la tension s’est correctement établie.
Wouah, maintenant vous savez tout sur le BOD ;) Merci Eric !
Terminons avec la partie basse du low fuse byte : 0001 au lieu de 1111, ce qui signifie qu’on est positionné sur l’horloge interne au lieu du cristal externe... Rien de grave sauf qu’on fonctionnerait à 1MHz au lieu de 8MHz.
Maintenant, cherchons l’origine de notre problème ! Regardons nos ordinateurs, et en particulier la ligne de commande d’avrdude qui en plus d’écrire le programme, peut servir à positionner les fuse bits.
Sur mon PC de bureau : j’utilisais la ligne de code "simple" (récupérée d’Eric) sans écrire les fusebits à chaque fois : aucun problème !
Sur mon PC portable utilisé en atelier depuis quelques semaines, j’utilisais l’exemple récupéré sur le site d’In-circuit : Ô malheur ! 0x99 et 0xC1, comme par hasard ;)
On a donc résolu le problème, merci Daniel, merci Éric pour tes articles, et merci In-Circuit pour nous avoir aidé à résoudre le problème en proposant la piste du watchdog et surtout envoyé trois nouvelles cartes en un temps record :)
Résultat : ça bagotte !
ICmega8 alive !
envoyé par JulienPobot
Pour aller plus loin
D’autres options sont disponibles via les fuse bits. Il existe un petit outil en ligne pour sélectionner la bonne valeur : http://www.engbedded.com/fusecalc