Donc, j'ai 5 cartes qui utilise une ATMEGA 2560 que j'ai conçue. Ils sont tous câblés correctement et ont été initialement capables de communiquer avec le studio Atmelstudio à l'aide d'un AVRISP MK2. La première planche a été capable de clignoter, d'avoir le verrou de verrouillage et des fusibles définis, après quoi il serait toujours capable de communiquer avec le programmateur. La deuxième carte a été initialement capable de flasher le programme et d'avoir le bit de verrouillage, mais après avoir défini les fusibles, j'ai eu l'erreur:
"Impossible d'entrer en mode de programmation. ISPenterProgMode: Statut d'erreur reçu: Got 0xc0, prévu 0x00 (la commande a échoué à exécuter sur l'outil)
Impossible d'entrer en mode de programmation. Vérifiez la sélection des périphériques, des paramètres d'interface, une alimentation cible, un bit de sécurité et des connexions sur le périphérique cible. "
Je n'ai pas pu lire la signature de l'appareil. Je pensais peut-être que c'était une puce faute, et puisque j'avais 3 autres planches à travailler avec je viens de l'ignorer. Lors de la programmation de la 3ème carte, j'ai traversé la même procédure et la même erreur est arrivée. Mais la 4ème Commission a travaillé lorsque vous faites la même chose.
Je suis toujours nouveau à la scène AVR et j'apprécierais toute aide pour que les 2 planches soient cassées pour travailler. Je sais ce n'est pas quelque chose qui ne va pas avec le cristal (16 MHz) ou le programmeur, ou même l'horloge ISP (125kHz). et ce n'est pas quelque chose avec le câblage. J'ai essayé d'effacer les copeaux défectueux, mais un incapable de le faire et empêché obtenir la même erreur. Y a-t-il un moyen de réinitialiser les puces pour stocker ou simplement pour rétablir les communications avec la puce.
La procédure était la suivante: 1) flashé la puce 2) Définir un bit de verrouillage sur "0xcf" 3) Définir des fusibles à "étendu 0xfd", "haut 0xd8", "faible 0xFF" 4) flash puce à nouveau et recevoir une erreur.
4 Réponses :
Fusible faible 0xFF signifie CKSEL3: 0 bits sont 0B1111. Cela signifie que l'oscillateur à faible consommation d'énergie est sélectionné (veuillez vous reporter 10.4 à la page 40 de la Datasheet ).
Un oscillateur à faible puissance pourrait être instable lors de la conduite de 16 cristal de 16 MHz et incapable de conduire un résonateur en céramique de plus de 10 MHz. Il peut être très sensible à la mise en œuvre et au bruit schématiques. Au lieu de cela, il est préférable d'utiliser un oscillateur à swing complet (byte à fusibles bas 0xf7). Vérifiez la mise en œuvre schématique, le type de résonateur et la capacité sur les broches XTAL.
Pour restaurer la connectivité ISP, vous pouvez désolé le résonateur et appliquer environ 1 vague carrée MHz sur la broche XTAL1 (voir 30,8 à la page 339 de la fiche technique).
Hé, merci, j'ai fini par utiliser un générateur de signal et je l'ai défini sur une onde sinusoïdale de 4 MHz sur laquelle l'oscillateur était, qui a rendu la puce communiquer à nouveau. Puis définissez le 0xF7 suggéré au fusible bas et tout fonctionne maintenant !!! Merci!!
J'ai eu cette erreur sur j'ai commencé à déboguer dans Atmel Studio 7.
Programmation de périphérique-> Informations sur le périphérique-> Recharger .
- solution est revenue au débogage (continuer avec F5) et fin de débogage avec
débogage-> désactiver Debugwire et Fermer.
Donc, si le débogage est exécuté, la programmation de périphérique est bloquée et une erreur supérieure est affichée.
J'ai reçu avec le même message d'erreur à ce fil, ma cause était une autre. Je me suis confondé Miso et Mosi.
Alors, comment de toute façon, la ligne Miso de votre FAI / débogueur / atmle-glace / etc. va à la miso-broche de votre automate. Mosi va à Mosi. Même lanble à la même place.
Donc, il n'y a pas de crossover comme la série TX-> RX RX-> TX, etc.
Essayez ces informations de Microchip Studio. Il a corrigé mon problème. Le fil de débogage a été défini d'utiliser une autre IDE et une autre session.