atmega328P muet ?

[somath]

Bonjour,
Je suis nouveau sur les forums, je me suis créé un compte parce que je suis face à un problème que je n'arrive pas à solutionner.
Je vais d'abord replacer un peu le contexte dans lequel je me trouve : j'utilise des Arduino Uno dans un cadre éducatif, j'en ai une 20aine dont certains sont tombés en panne au fil de l'eau, du fait certainement de mauvaises manipulations de mes apprenants.

J'ai donc plusieurs Arduino Uno en panne d'USB ; Atmega16U2 grillés apparemment dans la plupart des cas (voire à chaque fois). Je me suis lancé dans le remplacement de ces Atmega16U2. Opération que j'ai réussie jusqu'ici sur les 3 Arduino tentés, avec firmware+fuses gravés ensuite par USBasp.
Absolument tout ceci était nouveau pour moi, et je suis pas peu fier d'avoir réussi (et heureusement aussi, après avoir acheté du matériel pour souder, inspecter etc... Mais j'ai aimé bricoler ça en dépit des dépenses).

Sauf qu'apparemment, les Atmega328P de ces Arduino Uno ont grillés aussi ! Et on en vient à mon problème :

Ni une ni deux, je me dis que le plus difficile est derrière moi, et que le remplacement de ce composant se fera sans problème.
J'en commande donc des neufs, mais impossible de charger le bootloader (même avec les fuses) dedans. Pourtant j'y arrive sans problème avec un ATmega328P d'un autre Arduino fonctionnel parmi ceux qui fonctionnent encore.
Je me dis que les Atmega328P achetés sont "vides", je change donc de fournisseur, mais rebelotte, exactement le même problème.

Les Atmega328P semblent muets :

avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

Avez-vous des suggestions ? Besoin d'info supplémentaires ? Le fait que j'y arrive avec un ATmega328 d'un autre Arduino mais pas avec les nouveaux Atmega328 pourrait venir de problèmes de fabrication ? J'ai juste pas de bol avec mes deux fournisseurs (certes chinois) ?

[kamill]

Bonjour,

Comment charges tu le bootloader dans tes AUmega328p? Avec quel programmateur?

[somath]

Bonjour,
Merci pour ta réponse.

Pour charger le bootloader j'ai essayé plusieurs méthodes :

• Avec l'IDE Arduino1.8 :
  je branche mon USBasp sur le port ICSP qui est à côté de l'ATmega328P, Vcc en haut à droite.
  je sélectionne USBasp dans l'IDE -> outils -> programmateur:USBasp.
  je fais "graver la séquence d'initialisation" dans outil.

Cette méthode ne marche pas, mais fonctionne parfaitement avec un ATmega328P d'un des Arduino Uno fonctionnel (je remplace les ATmega328P sur la même carte Uno à chaque essai)

• Sans l'IDE Arduino :
  Je branche l'USBasp sur le port ICSP de la même manière l'autre méthode.
  J'utilise un fichier .bat qui utilise AVRdude dont je place le code en fin de post.
  J'ai les mêmes erreurs et mêmes symptômes : fonctionne avec l'ATmega328P d'un arduino au top de sa forme, mais ne fonctionne pas avec les ATmega328P achetés récemment.

Je crois n'avoir rien oublié...
Voici le contenu du .bat :

@echo off
echo === Gravure du bootloader pour Arduino Uno (ATmega328P) via USBasp ===
echo.

REM === Modifier ce chemin si necessaire selon l emplacement de l IDE arduino===
set AVRDUDE_PATH="C:\Program Files (x86)\Arduino\hardware\tools\avr\bin\avrdude.exe"
set AVRDUDE_CONF="C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf"

REM Verifie la presence du fichier avrdude
if not exist %AVRDUDE_PATH% (
    echo ERREUR : avrdude.exe introuvable. Verifie le chemin.
    pause
    exit /b
)


REM Chemin du bootloader (doit être dans le même dossier que ce .bat ou ajusté ci-dessous)
set BOOTLOADER="optiboot_atmega328.hex"

REM Vérifie la présence du fichier bootloader
if not exist %BOOTLOADER% (
    echo ERREUR : Le fichier %BOOTLOADER% est introuvable.
    pause
    exit /b
)

echo.
echo - Configuration des fuses...
%AVRDUDE_PATH% -C %AVRDUDE_CONF% -c usbasp -p m328p -U lfuse:w:0xFF:m -U hfuse:w:0xDE:m -U efuse:w:0xFD:m

echo.
echo - Televersement du bootloader...
%AVRDUDE_PATH% -C %AVRDUDE_CONF% -c usbasp -p m328p -U flash:w:%BOOTLOADER%:i

echo.
echo === Bootloader grave avec succes (si pas d erreur ci-dessus). ===
pause

[somath]

Je me pose la question, on est d'accord que lorsqu'on utilise la broche ICSP de l'ATmega328P, ça utilise le quartz de 16MHz automatiquement ?
Parce que je n'ajoute aucun autre composant.

[somath]

Je viens de tester avec une Breadboard et le package de l'IDE "Atmega328 on Breadboard at 8MHz internal clock" et ça fonctionne ! J'arrive avec faire blink une LED.

Par contre, je n'arrive pas à faire la même chose avec un ATmega328P d'un arduino fonctionnel : j'ai l'erreur comme quoi l'ATmega n'est pas reconnu lorsque j'essaie de graver le bootloader de 8Mhz..

Donc là je sèche complètement, quartz, pas quartz... ?
Y'a un Atmega328 qui fonctionne qu'en 16MHz et pas en 8Mhz même en essayant de graver le bootloader dans l'IDE, les nouveaux ATmega328 ne fonctionnent qu'en 8Mhz...

La solution est peut-être là :
Graver le bootloader 16Mhz avec mon USBasp et mon fichier .bat mais en passant par une breadboard et non pas par un Arduino Uno pour pouvoir communiquer avec l'ATmega328P cadencé à 8MHz ? Je vais essayer.

[somath]

J'ai résolu mon problème mais je ne comprends pas comment.

Il faut que :

• Etape 1, graver le bootloader 8MHz comme suit :
  -- mettre l'Atmega328P sur la breadboard,
  -- connecter un arduino as ISP sur les bonnes broches de la breadboard
  -- graver la séquence d'initialisation dans l'IDE Arduino avec les bons paramètres pour du 8MHz :
  

  

• Etape 2, graver le bootloader 16MHz :
  -- sortir l'ATmega328P de la breadboard et le replacer sur un Arduino Uno
  -- maintenant, la gravure du bootloader de l'arduino Uno fonctionne parfaitement en utilisant l'USBasp.

Je ne comprends pas pourquoi je dois graver un bootloader en 8Mhz pour ensuite pouvoir graver un bootloader en 16Mhz.
Dans le même genre, graver directement la séquence d'initialisation avec le bootloader 8MHz en utilisant l'USBasp en ICSP et un Arduino Uno ne fonctionne pas, peut-être à cause du quartz 16Mhz présent sur le Uno.

Problème résolu donc, mais si vous avez des explications je suis preneur. Je n'ai trouvé aucun tuto qui parle de toutes ces étapes intermédiaire pour graver un bootloader d'atmega328P

[fdufnews]

@somath

Je me pose la question, on est d'accord que lorsqu'on utilise la broche ICSP de l'ATmega328P, ça utilise le quartz de 16MHz automatiquement ?
Parce que je n'ajoute aucun autre composant.

Non, en sortie d'usine les ATmega sont par défaut en horloge interne.

De toutes les façons, l'ICSP apporte son horloge c'est une liaison synchrone (comme le SPI). Mais ensuite une fois le bootloader programmé il faut programmer les fusibles de l'ATmega pour faire générer l'horloge attendue par le bootloader.

[somath]

@fdufnews

De toutes les façons, l'ICSP apporte son horloge c'est une liaison synchrone (comme le SPI).

C'est à dire quelle horloge ? celle présente sur la carte UNO (16Mhz) ? Celle du programmateur (12MHz pour l'USBasp apparemment) ou celle qu'on définie dans le code source du bootloader peut-être ??

@fdufnews

Mais ensuite une fois le bootloader programmé il faut programmer les fusibles de l'ATmega pour faire générer l'horloge attendue par le bootloader.

Programmer les fuses se fait automatiquement avec le bootloader dans l'IDE Arduino j'ai l'impression non ?

[68tjs]

Oui et non.
Les deux opérations ne sont pas liées techniquement.

Ce qu'Arduino appelle "gravure de la séquence d'initialisation" consiste en :
— Modifier les fuses pour dévalider un diviseur par 8 de l'horloge → sorti de fab le micro tourne à 8 MHz divisé par 8 = 1 MHz.
— Modifier les fuses pour utiliser le quartz externe.
— Enfin graver un bootloader adapté aux nouvelles conditions.

Normalement avec la solution <<tout en un>> d'Arduino le micro devrait être fonctionnel.

[somath]

Oui donc c'est ok pour les fuses. Je ne comprends quand même rien à ce qui m'arrive...

Il faut que je grave la séquence d'initialisation avec un arduino as ISP dédié et mon microcontroleur sur la breadboard, et en 8Mhz. Ca à l'air de réveiller le microcontroleur. Ensuite seulement, je peux remettre le microcontroleur dans un Arduino et le graver en 16Mhz.

Si je commence en 16Mhz directement ça ne marche pas (logique j'imagine puisque je n'ai pas de cristal 16Mhz sur la breadboard) mais en plus, je n'arrive plus à repasser en 8Mhz après. Donc on dirait que les fuses ont été gravés quand même malgré l'erreur de AVRdude.

Au final j'arrive quand même à avoir des Atmega328 opérationnels et c'est le principal j'imagine.

[fdufnews]

@somath

Ensuite seulement, je peux remettre le microcontroleur dans un Arduino et le graver en 16Mhz.

Non tu le graves la première fois avec la fréquence à laquelle il sera utilisé en sélectionnant le bon type de carte dans le menu Outil. Le choix de la carte est important car il conditionne aussi la sélection des fusibles.
Ensuite tu l'installes sur la carte finale avec le bon quartz et il devrait fonctionner.

[Leptro]

se fut un temps j'ai utilisé ce genre de carte avec support zif (zero insertion force) pour programmer des atmega en version dip.

l'avantage, la présence d'un quartz pour l'horloge externe.

[somath]

Je vais refaire avec les images parce que je ne comprends pas de mon coté ce que tu veux dire.

Ca, avec l'USBasp branché en ICSP, ça ne fonctionne pas lorsque je grave la séquence.
Et ça ne fonctionne pas non plus lorsque je mets l'atmega328P sur la breadboard et que j'essaie avec l'USBasp et des fils volants.

Ca, Avec un Arduino Uno sur lequel j'ai téléversé le sketch ArduinoISP, et l'ATmega328P sur la breadboard, ça ne fonctionne pas lorsque je grave la séquence.

Ca par contre, ça fonctionne avec l'Atmega328P sur la breadboard et l'arduino as ISP branché avec des fils volants.
Mais ça ne marche pas avec l'USBasp branché sur la breadboard...

Au final, une fois que j'ai réussi l'étape avec l'option 8Mhz qui fonctionne, je fais tout ce que je veux sur l'atmega328P ensuite, je le remets sur un arduino uno, je grave la séquence avec l'USBasp en ICSP :

Et ça roule, je fais des sketchs Blink, y'a tout qui marche en USB et même en passant par l'ICSP. J'en suis à mon 5e Atmega que je fais comme ça, étape par étape, en essayant à chaque fois de trouver pourquoi ça foire avant mais sans succès.

Y'a qu'un truc que je n'ai pas réessayé récemment, c'est d'utiliser deux Arduino Uno, un en tant que programmateur et l'autre avec l'ATmega à programmer. Mais si ça ne marche pas au départ avec l'USBasp, je n'aurais pas plus de succès avec un arduinoISP j'imagine ? Et puis c'est ce que j'essayais avant d'acheter un USBasp.

Bref, je m'en sors au final, mais sans comprendre. Y'a sûrement un truc qui saute aux yeux mais invisible pour les miens, de néophyte en terme de bootloader... Pourtant, j'ai programmé mes atmega16U2 + fuses avec l'USBasp en lignes de commande avant ça sans problème (en vrai j'en ai bavé avant de trouver toutes les infos).

[somath]

Yes, merci pour l'astuce, j'avais vu ce p'tit composant utile mais vu mes problèmes, j'en ai déduit (peut-être à tort encore une fois) que ça ne me sauverait pas.