Depuis hier j'ai un souci avec mon Arduino Uno.
Je n'arrive plus à uploader de programme dedans, j'obtiens toujours le même message : "avrdude: stk500_getsync(): not in sync: resp=0x00".
Les LED Rx et Tx ne clignote pas.
Si j'appuie sur le bouton reset, la led L clignote.
Mon port COM, mon type de carte et de programmateur sont correctement sélectioné dans l'IDE.
J'ai un windows 7 x64.
Ce que j'ai essayé de faire après recherches :
Réinstaller les drivers
Réinstaller l'IDE
Faire un test de loopback (broche reset connecté à GND + Broche RX connectée à TX) : négatif, je n'ai pas d'écho de ce que je tape dans le serial monitor
Essayer de flasher un nouveau firmware dans le 8U2 en suivant ce tuto(pas réussi, je bloque avec FLIP et un problème de driver USB)
Sacrifier une vierge à Satan
Lorsque l'accident est arrivé je venais de mettre en route un circuit de controle de moteur CC avec un l298. Cela fonctionnait correctement. J'ai simplement débranché l'arduino du PC.
Bon bin ça sent l'Atmega32u4 défaillant ... Perso je vois pas 36 solutions et elle garantit rien : le reflasher
j'ai eu un probleme assez similaire avec un uno (apres l'avoir branché sur une box)
plus reconnu (perip usb dans les choux )
je n'ai jamais trouvé ce qui c'etait passé
il faut que je retrouve le topic
un test qui vaut ce qu'il vaut
Si possibilité faire une install sur un PC vierge d'arduino
Vérifie si L'IDE utilise bien l'option -D dans la ligne de commande avrdude
Pour cela ouvrir l'IDE--> préférences --> mode bavard et lancer un téléversement.
L'option -D efface systématiquement la totalité de la mémoire flash avant toute écriture d'un nouveau fichier hex.
Généralement quand je téléverse en ligne de commande avec un USBtinyISP je n'utilise pas cette option.
Sauf qu'une fois j'ai du prendre un fichier hex corrompu et j'avais bloqué une carte mini-pro et une UNO.
--> :"avrdude: stk500_getsync(): not in sync: resp=0x00"
J'ai récupéré ces deux cartes en utilisant l'option -D.
Mon arduino est bien reconnu par Windows (Arduino Uno COM5).
Pour le reflasher, je n'arrive pas a passer la carte en mode DFU. A aucun moment windows ne détecte un nouveau périphérique, il reste sur ce bon vieil "Arduino Uno COM5".
Mon arduino est bien reconnu par Windows (Arduino Uno COM5).
Pour le reflasher, je n'arrive pas a passer la carte en mode DFU. A aucun moment windows ne détecte un nouveau périphérique, il reste sur ce bon vieil "Arduino Uno COM5".
dans le gestionnaire de peripherique
lorsque tu debranche et rebranche le uno : tu vois disparaitre et reapparaitre ton COM5 uno ?
Artouste:
dans le gestionnaire de peripherique
lorsque tu debranche et rebranche le uno : tu vois disparaitre et reapparaitre ton COM5 uno ?
Affirmatif, le gestionnaire de périphériques m'indique bien Arduino Uno (Com 5). Et ce sur tous les ports USB de mon PC.
ok , donc pas du tout les memes symptomes que pour moi
là je penche (mais sans plus de certitude ) sur un 328 "pas/plus" en forme (corruption de bootlaoder) pour tailler la "bavette" avec le 8U2
l'ideal pour test serait que tu remplace le 328P "bootloadé" par un autre "certifié clean"
sur du uno c'est simple c'est du DIP sur support, le plus compliqué selon où tu es, est de recuperer un 328 pré-chargé
Pour tester le loopback, il faudrait retirer l'ATmega et réunir D0 et D1.
Connecté au PC et ouvrir un hyper terminal ou n'importe quoi du même genre
Les caractères émis par le terminal devraient lui être retournés.
Cela dédouanerait l'Atmega32u4
J'ai retiré le 328 de la platine et j'ai refait un test de loopback (D0 et D1 reliées) : je n'ai toujours aucun écho de mes caractères dans le serial monitor.
J'ai replacé un vieux 328 un peu estropié, mais fonctionel : Toujours aucun résultat lors du téléversement. Tx et Rx ne clignotent pas.
Ca devient étrange ... La reconnaissance dans le gestionnaire montre que l'Atmega32u4 gère bien la connexion USB et est donc bien "vivant". Peut-être que lors de tes manips tu as flingué les sorties :s
Tu peux me dire bienvenue au club des "Avrdude not in sync".
Les choses ont évoluées dans le mauvais sens.
Carte UNO R2.
Comportement pour le moins étrange :
Pas de programmation possible à partir de l'IDE -> "avrdude not in sync"
Programmation possible en ISP.
Jusque là il n'y a rien d'anormal si on considère que l'USB est hs.
Mais il y a plus fort :
Après avoir été programmée en ISP elle cause par l'USB dans un terminal Linux. Si j'ouvre l'IDE et le Serial-Monitor la carte UNO cause aussi dedans ! C'est que l'USB n'est pas si hs que ça.
Remarque : je n'ai pas testé dans le sens terminal vers carte
Je sens qu'un rechargement du firmware devient une nécessité.
La carte ayant été livrée un peu buggée, j'ai déjà du faire cette opération mais en mode DFU qui est casse bonbons. Maintenant que j'ai un USBtinyISP je préférerais éviter.
Problème possible : c'est une R2 équipée d'un 8U2, les UNO actuelles sont équipées d'un 16U2 et même d'un 32U2.
Le changement de micro (8U2 -> 16U2 -32U2) c'est juste une demande du sous traitant pour uniformiser ses approvisionnements et réduire les coûts où c'est pour avoir un firmware plus gros ?
Pour récupérer le bon firmware faut-il télécharger une ancienne version de l'IDE ?
Comment choisir laquelle ?
Pas de programmation possible à partir de l'IDE -> "avrdude not in sync"
Programmation possible en ISP.
Jusque là il n'y a rien d'anormal si on considère que l'USB est hs.
Mais il y a plus fort :
Après avoir été programmée en ISP elle cause par l'USB dans un terminal Linux. Si j'ouvre l'IDE et le Serial-Monitor la carte UNO cause aussi dedans ! C'est que l'USB n'est pas si hs que ça.
Remarque : je n'ai pas testé dans le sens terminal vers carte
...
Problème possible : c'est une R2 équipée d'un 8U2, les UNO actuelles sont équipées d'un 16U2 et même d'un 32U2.
bonjour 68tjs
lorsque tu injecte par ISP un programme "kikause dans le poste " tu recupere les infos "prevues" sur un terminal ?
Artouste:
bonjour 68tjs
lorsque tu injecte par ISP un programme "kikause dans le poste " tu recupere les infos "prevues" sur un terminal ?
Oui c'est ça qui est fantastique. Dans un terminal externe ET dans celui de l'IDE.
@Batto : je ne l'ai pas encore fait mais comme un sens fonctionne cela apporterait je pense moins d'information qu'un programme qui recevrait et enverrait des données .
Je vais chercher un exemple tout fait où on entre des données dans le micro, histoire de tester les deux sens. Il n'y a peut-être qu'un seul sens qui est affecté ce qui expliquerai que ça cause du micro vers l'USB et que ce serait muet de l'USB vers le micro
PS1: je me garderais bien de dire que je n'ai pas fais subir des outrages a la bébette.
PS2 : J'utilise la version Debian qui est organisée selon le principe Debian, pour trouver plus simplement les firmwares j'ai téléchargé la version sur le site.
Dans les firmwares j'ai trouver un fichier hex pour le 8U2, un autre pour le 16U2 et un fichier README qui me laisse penser que je pourrai recharger le fichier hex par l'intermédiaire du connecteur ISP situé à coté la prise USB. ou faut-il passer en DFU ?
J'ai l'impression que que cela devrait le faire en ISP, mais si quelqu'un pouvait confirmer avant que j'achève la bête pour de bon.
Oui mais justement c'est pour savoir si c'est pas le TX de l'Atmega32u4 qui est mort
Tu peux reflasher l'Atmega32u4 en ISP, y'a plusieurs démo sur le net de type qui l'utilise justement pour faire autre chose. D'ailleurs tu peux tester en lui chargeant le bootloader de la leonardo
UNO connectée normalement au PC -> ouverture du port /dev/ttyACM0
Broches TX et RX de la UNO raccordées sur une interface USB/TTL (celle dont l'électronique tient dans la fiche USB) ouverture d'un port /dev/ttyUSB0
Si j'utilise le serial monitor de l'IDE pour envoyer des caractères je peux les lire en echo par l'intermédiaire du convertisseur USB/TTL.
En confirmation la del RX de la platine UNO clignote.
Le problème n'est donc pas matériel, il doit être logiciel.
Je n'ai pas d'autre UNO, rien que des mini-pro sans USB. Je vais de ce pas approvisionner une Nano parce que le format de la carte UNO et de ses connecteurs me sortent par les yeux.
Quant au logiciel je vais faire des fouilles archéologiques vu que j'ai aussi pris quelques liberté de ce coté là.
Merci pour votre participation.
68tjs:
Vérifie si L'IDE utilise bien l'option -D dans la ligne de commande avrdude
Pour cela ouvrir l'IDE--> préférences --> mode bavard et lancer un téléversement.
L'option -D efface systématiquement la totalité de la mémoire flash avant toute écriture d'un nouveau fichier hex.
Généralement quand je téléverse en ligne de commande avec un USBtinyISP je n'utilise pas cette option.
Sauf qu'une fois j'ai du prendre un fichier hex corrompu et j'avais bloqué une carte mini-pro et une UNO.
--> :"avrdude: stk500_getsync(): not in sync: resp=0x00"
J'ai récupéré ces deux cartes en utilisant l'option -D.
