Hatte ich auch schon mal,
ich hatte den Prozessortyp nicht richtig eingestellt.
Ich hab,s gerade ein STK500 gekauft, und gleich ausprobiert.
Dabei wird eine Fehlermeldung ausgegeben "Entering programming mode....FAILED"
und bei "FUSES","LOCK BITs" wird es auch solche Fehlermeldung-
"Problems occurend when executing command(s). Pleas check the history window."
Ich bin nicht so gut im Englisch, kann mir jemand sagen, was sind die Fehlermeldungen und was kann ich dagegen machen.
Danke!
Hatte ich auch schon mal,
ich hatte den Prozessortyp nicht richtig eingestellt.
das kann eine Menge Ursachen haben fange mal damit an auf der Reiterkarte BOARD das Voltage und den quarz einzulesen.
Wenn er das macht dann funzt schon mal die Verständigung mit dem Board an sich.
Dann auf ADVANCED und Read Signature. Das funzt vermutlich schon nicht. Also unter Programm -Device prüfen ob der richtige MC-Typ ausgewählt ist. Ist er das und gehts trotzdem nicht..
prüf mal die Verbindungen auf dem STK an. Alle Jumper korrekt? Prozessor im richtigen Sockel?
ISP6PIN mit dem richtigen SPROG -Stecker verbunden (Farbcode) usw.
mach erst mal bis dahin, wenns immer noch nicht geht meld dich wieder.
byPö
Hallo,
hab das gleiche Problem mit einem ATMEGA64!
Weiß nicht mehr weiter,... habe alles ausprobiert, was oben steht!
Kann mir noch jemand einen Tipp geben?
mfg
SMILEY
Hallo,
mir geht es genauso, hab einen ATMega32, den ich nicht programmieren kann. Und der ATMega8551 der mitgeliefert wurde zeigt auch:
Entering programing mode.. FAILED!
Hab alles bis dahin auch durchprobiert wie Pö beschrieben hat, aber wie gehts weiter ???
Hat das Problem schon jemand gelöst, oder kennt jemand die Ursache ???
Grüsse
Hi,..
bei meinem Atmega64 lag es daran, daß die Pins MISO und MOSI nur für SPI-Kommunikation und nicht für ISP-Uploads zur Verfügung stehen. Für ISP gibts am Atmega64 die Pins PDI und PDO. Aber soweit ich weiß hat der AtMega32 keine derartigen Pins. Also mußt du es weiter versuchen.
BTW: Vielleicht hilft es: Ich habe einen Atmega8 mit gleichem Problem, wenngleichzeitig eine Kommunikation über SPI stattfindet. Sobald man das Kabel abzieht funktiert es.
LG
SMILES
Meine Erfahrungen dazu:
Ursache 1: STK500 nicht erkannt -> serielle Schnittstelle blockiert -> blockierendes Programm (z.B. Hyperterminal) schliessen.
Ursache 2: Controller-clock und Board-Clock nicht abgestimmt -> meist sind die AVRs auf internen Takt mit 1MHz voreingestellt. Der ISP-Takt darf dann nicht über 250kHz liegen -> Board-Takt auf Mindestwert reduzieren (32kHz) und danach die Fuse settings ändern. Danach kann dann der Board-Takt wieder höher gedreht werden (sonst dauerts zu lange)
Ursache 3: Die Fuse für das serielle ISP steht auf "disable". Dann ist serielle Programmierung gesperrt -> µC gemäß Doku mit paralleler High Voltage programmieren - DABEI DIE FUSE FÜR DAS SERIELLE ISP UMSCHALTEN
Ursache 4: Die Security Fuses sind gebrannt und der Chip ist gegen "Datenklau" geschützt -> "Erase entire chip" (also komplett putzen) und alle Fuses kontrollieren (kann dann zu Ursache 2 oder 3 führen!)
Ursache 5: Die Pins für's ISP sind anderweitig belegt, die Schaltung verträgt sich nicht mit ISP -> AVR alleine (keine Ports belegen!!) in das STK500
Ursache 6: Der RESET-pin ist als alternativer Port gefused -> serielles ISP nicht machbar, nur paralleles high-voltage
Ursache 7: Der RESET ist nicht im STK500 angeschlossen (z.B. ATtiny26) -> zusätzlich verdrahten - ist im Handbuch genauestens beschrieben!
Ich habe bisher keinen AVR in die Finger bekommen, der sich nicht durch eine der beschriebenen Maßnahmen zur Kooperation überreden lies. Falls serielles ISP ums verrecken nicht funktionieren will, den AVR mit der prallelen High-Voltage-Methode behandeln und alle Fuses kontrollieren.
Ist der AVR nicht auf dem STK500, dann können noch weitere Ursachen mitspielen, dafür kann das STK500 aber nix - da ist der Designer der Schaltung zuständig. Die muß gewisse Randbedingungen erfüllen, damit sie ISP geeignet ist!
a) Es gibt keine dummen Fragen, nur dumme Antworten
b) Fehler macht man um aus ihnen zu lernen
c) Jeder IO-Port kennt drei mögliche Zustände: Input, Output, Kaputt
Hallo H.A.R.R.Y.,
Ich bin leider erst Anfänger und noch nicht sehr vertraut mit dieser ganzen Geschichte.
Ich kann zwar im Parallel/High Voltage-Modus Daten lesen aber nicht die Fuses auf SPI umstellen ohne dass ein Fehler aufritt.
Die Einstellungen für die Oszis hab ich auch heruntergesetzt (Siehe Anhang)
Ich weiss gerade nicht wie ich genau weitermachen soll......
Hallo Bunch,
ich finde den erwähnten Anhang nicht - schade. Außerdem setze ich mal voraus, daß Du die Doku zum STK500 (das gebundene Heftchen) gelesen hast, BEVOR Du die ersten Experimente startest. Irgendwo ist auch so eine Art Mini-Tutorial zu finden (bloß wo?) wo die ersten Schritte mit dem AT90S8515 erklärt sind.
Solltest Du das noch nicht gemacht haben - bitte nimm Dir die Zeit und gehe das Schritt für Schritt durch.
Ansonsten - let's debug:
Das STK kommuniziert mit dem PC - RS232 ist somit ok
Du hast Dir das STK frisch gekauft, da ist dann mindestens ein AT90S8515 beigelegt: Der ist mit einem Demo-Programm vorprogrammiert.
FRAGE1: Geht dieses Demo-Programm?
FRAGE1a: Steckt der Controller im richtigen Sockel? Siehe Handbuch!!
Wenn Du das Programmieren startest, geht das Statusfenster auf. Dort gibt es jede Menge Einstellmöglichkeiten:
FRAGE2: Welche Betriebsspannungen sind für das Board eingestellt (<Board> -> voltages)?
FRAGE3: Welcher Boardtakt ist eingestellt (<Board> -> STK500 Osc. / ISP freq.)?
FRAGE4: Welcher Controller ist ausgewählt (<Program> -> Device)?
FRAGE5: Welche Programmiermethode ist ausgewählt (<Program> -> Programming mode)? Die muß korrekt ausgewählt werden, das STK erkennt sie nicht automatisch!
FRAGE6: Hast Du den parallel/HV-Modus (oder auch serielles ISP) exakt nach Doku verdrahtet (die Kabel, die Jumper)? Sind die 10poligen Portstecker alle frei oder hängt da was dran?
FRAGE7: Was liefert "Read Signature" (<Advanced> -> Signature bytes)?
FRAGE8: Welche Fuses sind gesetzt?
FRAGE9: Welche Daten kannst Du lesen? Das EEPROM oder das FLASH?
FRAGE10: Ist die zu programmierende Datei richtig ausgewählt? Spielt hier eine untergeordnete Rolle, ist aber immer mal wieder zu kontrollieren. Es haben sich Leute schon extrem gewundert warum ihre ganzen Änderungen im Sourcecode ums verrecken nicht im Controller landeten...
FRAGE11: Bei welcher Aktion tritt die Meldung "Entering programming mode .... FAILED" auf?
Stimmt, da war ja noch was: Du verwendest hoffentlich ein Netzteil wie angegeben? Falls das den Programmierstrom nicht schafft könnte das auch noch den Fehler auslösen...
Falls das alles nicht hilft: eMail an ATMEL's helpline - ist auch im Handbuch vermerkt
a) Es gibt keine dummen Fragen, nur dumme Antworten
b) Fehler macht man um aus ihnen zu lernen
c) Jeder IO-Port kennt drei mögliche Zustände: Input, Output, Kaputt
Hallo,
hatte das gleiche Problem mit dem ATTiny 2313.
Der Fehler liegt in der Einstellung der FuseBit`s bzw der LockBit`s.
Folgene Vorgehensweise empfehle ich dir.
1. Prozessor in die richtige Fassung stecken SCKT3300D3 stecken (tiny2313)
2. Bord auf Parallelmodus umstellen s. Anleitung.
3. AVR-Software starten
4. Schnittstelle einstellen(schwarzes Buttem,Con) am Besten auf Auto stellen
5. auf AVR Buttem drücken
6. Maske öffnetet sich
7. über Maske Program Controllertyp einstellen und
Chip löschen, über "Chip Erase"
8. LockBits müssen jetzt auf Mode1 stehen, wenn nicht , entsprechender Mode anklicken und über das Buttem "Program" übertragen
9. FuseBit müssen auf
Serial program downloading (SPI) enabled;(SPIEN=0)
Brown-out detection disabeld;(BODLEVEL=111)
und irgend ein Ex Clock z.B 8 MHz
10. Einstellung mit Buttem Program übertragen.
11. umstecken auf SPI-Modus und Testen.
Sollte es immer noch nicht Klappen melde dich.
Gruss konne
Lesezeichen