Hallo Nachtschwärmer, mein (fast) neuer AVR-ISP MKII treibt mich noch in den Wahnsinn. Ich schildere mal der Reihe nach. In letzter Zeit erhalte ich immer die Fehlermeldung aus dem Anhang und der ATMega-8/32 ist verloren. Egal wie ich an den Parametern (ISP-Frequenz;Fuses;..) im Übertragungsprogramm (AVR-Studio) drehe, der Chip kann nicht mehr angesprochen werden. Gut die ersten Mal habe ich noch an einen Fehler in der Außenverschaltung / Spannungsversorgung meiner Platine geglaubt, jedoch ist diese fest. Es wird also außer der Software nichts verändert. Nach ca. 30 bis 50 mal Programmieren tritt der Fehler auf und das wars für den Chip. Stecke ich einen neuen ATMega in die Fassung kann ich wieder programmieren, doch ist da auch nach 30 bis 50 mal Schluss und ich brauche einen neuen Chip. Auch ein Neustart des Rechners oder das Ein- und Ausstecken der USB to MKII-Verbindung brachte keine Änderung. Der ATMega konnte nie wieder angesprochen werden. So habe ich in den letzten 2 Wochen ca. 10x den Chip gewechselt, mit dem Aspekt "Ok der ist Schrott!". Aber jetzt kommt das Kuriosum: =============================== Gerade habe ich vor Wut mein altes paralelles Übertagungskabel, hier vom Shop, angeschlossen und siehe da, der vermeintlich defekte Chip konnte plötzlich über LPT mit Pony-Prog progammiert werden. Also die "Schrott-" ATMegas rausgekramt und wie man schon vermutet, auch diese konnte ich wieder beschreiben. OK, die Chips sind also nicht defekt, zu Glück habe ich sie noch aufgehoben. /Vermutung ON Nunja, vielleicht ist das ähnlich der HV-Programming und bei LPT-Übertragung werden im Hintegrund noch igendwelche wichtige Fuses/Bits überschrieben. Also probierte ich das Ganze noch mal mit der AVR-ISP MKII. Keiner der "Schrott-" MCs konnte erneut angesprochen werden, als ob sich die MKII die ATMegas "gemerkt" hätte. Gebe ich ihr (MKII) aber einen neuen Chip zu fressen, erkennt sie ihn wieder eine Zeit lang. /Vermutung OFF Noch etwas wichtiges: --------------------- Der ganze Port_B(Mega_32) ist nicht per Außenbeschaltung belegt, d.h. die Pins für MISO, MOSI, SCK stehen nur für die ISP-Übertragung zur Verfügung. Also meine Frage: Hat irgend Jemand in dem Universum auch diese Probleme oder stehe ich hier auf weiter Flur? Gute Nacht Stevko
Angehängte Dateien:
-
Error_1.jpg
36 KB
Mach mal ein Foto von deiner Anlage. Ich hatte so was, bei einem Mega8. Da war nicht genug C Buffer auf dem Board. 100 uF rein. Reset-Beschaltung. Das Flashen braucht schoon was an Energie. Hast du ein Scope ? Am z.B STK 200 ist ein Pull-Up 100 K dran. MISO , also der an Pin 10 an der LPT geht. Falls der Pull-Up den Ausgang der MCU von deinem USB Teil nicht mehr so gut pullt, wird das LOW nicht mehr so gut übertragen. Mach mal an den Ausgang der MCU wie beim z.B STK 200 einen 100K Pull-Up dran. 1) Mit AVR-Dude kann man auch so einen art Echo-Test (Loop Back ) machen. Ohne die MCU dabei zu haben, somit kann man sehen ob die Strecke geht. Die Befehle dafür weiss ich leider nicht mehr. Lasse dir da Infos Zukommen Dazu verbindet man Miso über 1 K Ohm mit Mosi. Am StatusFenster im AVR-Dude sieht man via Text die Inputs->Outputs . Mit dem Scope kann man die Pegel ansehen. Gruss Holger.
Glaskugel sagt: Ersetze die 3,5 m Flachbandkabel zwischen ISP und Board durch 15 cm Kabel, schmeiß den selbstgemachten 6-Pin auf 10-Pin Adapter weg und schließ gefälligst VTG richtig an.
Ich habe genau die gleiche Fehler gesehen aber in meinem Fall ich habe die debugWire fuse aktiviert und ich wusste nicht daß man die Fuse zuerst per debugWire deaktivieren sollte.
Schon mal dran gedacht, dem atmel-Gekruschtel den Rücken zu kehren ? Beim Zilog encore! gibt es solche Mysterien nicht. :-) Gruß und viel Glück vom einsamen encore-user !
Hi >Schon mal dran gedacht, dem atmel-Gekruschtel den Rücken zu kehren ? >Beim Zilog encore! gibt es solche Mysterien nicht. >:-) >Gruß und viel Glück vom einsamen encore-user ! Erzähle das mal dem Tausenden, bei denen das problemlos funktioniert. MfG Spess
Einen schönen Sonntag an Alle, @Holger: Ich wollte es nicht zu ausführlich schreiben aber ich habe bei mir noch andere Test-Boards. Wenn ich den "verlorenen" Chip in diese funktionierenden Boards sockle, kann die MKII ihn auch nicht erreichen. Es ist als ob sich die MKII den Chip "merkt" und wenn sie mit ihm verbunden wird, sagt sie obligatorisch "NO GO!". Mit der LPT-ISP kann ich den Chip aber trotzdem Flashen. Das mit den Pull-Ups werde ich probieren, aber wieso funktioniert die Übertragung ca. 50x tadelos und dann nie wieder? @ Hier steht ein Name (Gast): >Glaskugel sagt: Ersetze die 3,5 m Flachbandkabel zwischen ISP und Board >durch 15 cm Kabel, schmeiß den selbstgemachten 6-Pin auf 10-Pin Adapter >weg und schließ gefälligst VTG richtig an. Bitte lese doch einmal meinen Thread richtig durch und versuche mein Anliegen zu erfassen. 1. die LPT-ISP funktioniert tadelos --> kein Flachbandkabelwechsel nötig 2. VTG ist richtig angeschlossen sonst würde es nicht 50x funktionieren bzw. mit LPT-ISP auf Ewig funktionieren Für alle, wie "Hier steht ein Name" noch einmal die Kurzfassung: ---------------------------------------------------------------- 1. MC egal welcher, Mega_8 16 32 wird per AVR-MKII programmiert 2. die Schaltung in welcher der MC steckt wird nie verändert 3. nach 30-bis 50x kann der MC über die MKII nicht mehr erreicht werden / siehe Fehlermeldung im Anhang 4. MC wird durch einen neuen MC ersetzt, dann kann der Neue wieder eine Zeit lang geflascht werden bis der Fehler erneut auftritt --> wieder neuen MC in Schaltung 5. verbindet man die Schaltung mit LPT-ISP dann kann der "defekte" MC plötzlich beschrieben werden 6. verbindet man den "reanimierten" MC wieder mit der MKII wird dieser wieder nicht erkannt, bis in alle Ewigkeit ist dieser MC für die AVR-MKII verloren, egal in welcher Schaltung er steckt Gruß Stevko
@ Alejandro P. s.:
>Ich habe genau die gleiche Fehler gesehen ...
Super und "Ohrenaufstell".
Leider bin ich gerade bei meinen Patenkindern und muss das Mittag
kochen.
Wenn Du Zeit hast, kannst Du mir bitte schreiben wo und wie Du den
"debugWire" deaktivierst. Da Übertragungsmenü der MKII habe ich in etwa
im Kopf.
Gruß
Stevko
Stevko R. schrieb: > Wenn Du Zeit hast, kannst Du mir bitte schreiben wo und wie Du den > "debugWire" deaktivierst. Den debugWIRE kann man nur per debugWIRE deaktivieren. Das kann's hier nicht sein, denn wenn der aktiv ist, dann kommt kein ISP rein, egal welches, weil ISP ohne Reset-Leitung nicht geht.
Bernhard G. schrieb: > Beim Zilog encore! gibt es solche Mysterien nicht. Dafür aber auch keine kompatiblen Chips, z.B. für den ATtiny25 (1,8-5,5V, DIP8). Das MK2 läuft bei vielen ohne Probleme. Und es wird auch Leute geben, die mit dem Zilog Probleme haben. > Gruß und viel Glück vom einsamen encore-user ! Ja, das ist der Preis bei exotischen MCs, man hat wenig Hilfe in Foren. Ich hab noch einige Stangen UB8841 rumliegen, das sind DDR-Typen des Z8 im 4-reihigen Gehäuse zum Anschluß eines externen 4kB EPROM. Peter
also, um es noch kürzer zusammenzufassen: durch einen irgendwie fehlerträchtigen Aufbau werden die uCs durch einen Übertragungsfehler (Brummschleife, ÜBersprechen, Stromversorgung, etc...) umprogrammiert oder evtl. beschädigt, dass ein Zugriff nur noch mit dem LPT-ISP funktioniert ... also, wo genau ist der Unterschied in Deinem Falle zwischen LPT-ISP und MKII? Läuft letzterer evtl. mit 3.3V oder so? Im Zweifel ist der MKII auch deutlich schneller, vielleicht geht da was schief. Kannst Du die uCs mal in allen FuseBits auf default stellen (vielleicht mit einem 'funktionierenden' vergeleichen?) Gruss, Ingo.
Ich sehe gerade, das es Menschen gibt, die genau das gleiche Problem wie ich haben ... Bei mir konnte ich keine Schaltung mehr programmieren, nachdem ich den AVR ISP MK II bekommen habe. Mit dem STK 500 bzw. STK 200 konnte noch programmiert werden. Fehlermeldung aus dem AVR Studio war dieselbe, wie oben im ersten Beitrag. Meine Lösung hieß: Die Resetbeschaltung war schuld. Wenn ich den C aus dem RC Glied beim Proggen mit dem MK II rausnahm ging es, wenn der drin war dann war es so ähnlich wie Lotto ... ein paar mal komplett, dann Abbrüche und dann nie mehr. Keine Ahnung, woran das liegt. Ich mache seit dem immer einen Jumper in die Platinen (oder eine Brücke) den ich entferne, wenn ich proggen will. Dann ist während des Proggens eben keine RC Beschaltung am Reset. Gruß vom Problemhaber
Angehängte Dateien:
-
dsc01844kl.jpg
260 KB -
AVRxN_Res1.jpg
170 KB
@Stevko R Mach mal bitte ein Foto von der Anlage. 1) Das reicht nach MCU_Ext.Reset-Beschaltung. Mach mal erst nix mit den 100K Pull-Up. Klemme mal den externen C am /Res-Input des AVR's ab ! ( ca. 100nF ) ------------------------------------------------------------------------ --------------- (Normal reicht ja ein 10K Pull-Up am /Res-Input_AVR-MCU) Die neueren AVR-MCU's vefügen ja schon über einen eigenen internen Reset-Controller ------------------------------------------------------------------------ ---------------- Bzw. Unterstützen die speziellen Fuses für SUT (Start-Up-Timer). Falls man im "Kalt-Start" in der Power-Up Anwendung Probleme mit Fast-rising bzw. slow-rising Power bekommt. (Gerade bei 3,3 Volt MCU's. hat mein Bruder das schon erlebt) ------------------------------------------------------------------------ ------------------ Der AVR MKII legt wohl einfach nach seinem /Reset kurz darauf los, mit seinem ISP Protokoll. (Wird der /Res Level auch zurückgelesen). Sicher kann man die Reset-Hold & /Res_Wait Zeit am AVR MKII einstellen. ------------------------------------------------------------------------ ------------------------------------ @Problemehaber Das mit dem Jumper am ext. C zu /RES ist gut. ------------------------------------------------------------------------ ------------------------------------ Gut das ich jetzt die AVR's reanimieren kann. Die /Res-MCU Level-Schmitt-Trigger Hysterese nutz sich wohl ab, wie die Sohle von Schuhen. ISP Beschaltung vom Innenleben von dem AVR MKII 5 mal Serielle Rs zur Strombegrenzung ??? Wird der /Res Level auch zurückgelesen?. Viel Erfolg. Gruss Holger.
Jumper ist nicht nötig, laut Manual sind max 10µF / min 4.7k erlaubt. Ich benutze 0.1µF / 10k. Peter
Guten Abend an Alle, komme leider erst heute dazu die Fragen zu beantworten. @PeDa: ======= >"Das" MK2 läuft bei vielen ohne Probleme. Ok, wieder was gelernt, es heist das MKII. >Jumper ist nicht nötig, laut Manual sind max 10µF / min 4.7k erlaubt. >Ich benutze 0.1µF / 10k. Peter funktioniert bei Dir das MKII tadelos? Ich habe die gleiche Kombination wie Du, doch bei mir und bei "Problemehaber" kommt es zu massiven Komplikationen. @Ingo: ======= >Läuft letzterer evtl. mit 3.3V oder so? Also mein Voltage-Monitor zeigt die 5V an, das wäre ok. >Kannst Du die uCs mal in allen FuseBits auf default stellen Ich habe bei meinen uCs (8/16/32) immer die gleichen Einstellungen, mal sehen ob das was bringt. >Im Zweifel ist der MKII auch deutlich schneller, vielleicht geht da was >schief. Da fällt mir in dem Zusammenhang (siehe auch "Holger Harten" weiter unten) noch etwas ein. Man kann ja die Start-UP-Times einstellen. Hier habe ich bis jetzt die höchste Stufe=65ms gewählt. Vielleicht sollte ich einmal auf "Fast-Rising-Power"=4,1ms umstellen. --> Peter bei Dir funktionierts ja, was für eine Start-Up-Time hast Du? @Problemehaber: ================== Du hast mich gerettet bzw. aufgebaut! Habe schon selbst an mir gezweifelt, da ich hier im Forum nichts dazu gefunden habe. Die Sache mit dem Kondi klingt auch logisch und das werde ich auf jeden Fall probieren. Wann hast Du deine MKII bekommen? Meine ist jetzt 2 Monate alt und macht nur Probleme. Vielleicht haben sie eine neue Serie aufgelegt, denn bei "PeDa" und vielen Anderen funktionierts ja einwandfrei. Und ich habe auch die gleiche Resetbeschaltung wie die anderen. @Holger Harten: ==================== Vielen Dank für Deine Gedanken/Beiträge. Ich will auf jeden Fall das Problem lösen und der Sache auf den Grund gehen. >Mach mal bitte ein Foto von der Anlage. Holger, meinst Du das MKII oder meine Platinen? Ich habe hier ca. 10 Boards für die ATMega 8/16/32, die vorher tadelos zu Programmieren waren. Die Restebeschaltung ist bei allen gleich, 10k und 100nF-Kerko. Egal in welche Platine ich den "abgewiesenen" uC stecke, das MKII will nicht kommunizieren. Mit "Parallel-ISP" ist es kein Problem. >Mach mal erst nix mit den 100K Pull-Up. Ich glaube Du meinst 10K-Pull-Up. ;-) >Klemme mal den externen C am /Res-Input des AVR's ab ! Ja das werde ich versuchen (siehe "Problemehaber") und dann berichten. >Der AVR MKII legt wohl einfach nach seinem /Reset kurz darauf los.. Du musst jetzt bei: "@Ingo" nachsehen. ;-) / Gute Idee! >Die /Res-MCU Level-Schmitt-Trigger Hysterese nutzt sich wohl ab, >wie die Sohle von Schuhen. Könnte dies die Ursache für mein Problem sein, dass ein einmal "abgewiesener" uC nie wieder mit dem MKII zu erreichen ist. Aber wie kann sich ein Schmitt-Trigger "abnutzen"? Hättest Du bitte eine I-Net-Seite oder eigene Worte zu dem Thema. Bis jetzt glaubte ich an natürliche Alterung von Bauteilen. Gute Nacht Stevko
Stevko R. schrieb: > --> Peter bei Dir funktionierts ja, was für eine Start-Up-Time hast Du? Immer die längste (habs nicht eilig) und Brownout = 2,7V. Vielleicht hilft das hier: http://www.atmel.com/dyn/resources/prod_documents/avrisp_mkii_fix.html Peter
@PeDa: >Immer die längste (habs nicht eilig) und Brownout = 2,7V. Ok, habe ich auch. >Vielleicht hilft das hier: Man Peter, wo hast Du immer solche Sachen her? Leider ist das MKII später gebaut --> der Fix bringt nichts. Trotzdem Danke für die Hilfe. Werde am Wochenende die Sache ohne Kondi am Reset testen. Gruß Stevko
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.