Ich habe 2 identische Boards mit ATmega64L gebaut, das eine funktioniert einwandfrei, das andere am Anfang auch, dann habe ich das mal in der Runde rumgegeben und seither meldet uisp immer Schreibfehler beim Flashen und nun gar nichts mehr (Ob Strom verbunden sei, Korrekt verdrahtet ?) Quarz schwingt nicht mehr. Auch wenn ich auf XTAL1 einen externen Takt gebe (400kHz + 1 MHz) passiert nichts. Den Fehler können nur 2 Möglichkeiten ausgelöst haben: 1) Jemand hat mit aufgeladenen Fingern auf einen Anschluss gefasst, besonders exponiert Reset, SCK, MOSI + MISO, also Tod durch Elektroschock... 2) Beim Umstecken könnte PF7 als Ausgang kurz +5V erhalten haben (das probiere ich nicht am anderen Board). Ich habe beim Auslesen der Fuses das Oszi an Reset, SCK, MOSI + MISO gehalten und da waren auch überall Signale zu sehen, was kann da klemmen ? 1 oder 2 sollten einen AVR doch nicht killen, oder doch ?
Kannst du die beiden ATMegas mal vertauschen (also beide auf das jeweilige andere Board)?
Das würde nichts bringen, es geht nur um den AVR selbst, das Bord ist nur Kupfer zwischen AVR und Steckverbinder und alle Verbindungen habe ich erfolgreich durch geklingelt.
Wie kann ich testen, was noch funktioniert ? Der Aufwand für parallele Programmieren ist aber zu hoch. Ohne Betriebsspannung sollten 5V an einem Port den AVR doch nicht killen, oder ?
miss mal die Spannung an den I/O Pins bei Betrieb und während Reset aktiv ist. Ich hatte mal ein ähnliches Problem mit Atmega644. Hab ihn dann aus der Schaltung genommen, ein paar Minuten auf ein leitendes Pad gesteckt und anschließend wieder zurück in die Schaltung. Und siehe da, er war wieder am Leben, bin aber heute noch unsicher was die Ursache anbelangt...
Beim ATmega64 kann man sich nicht versehentlich aussperren, nur den Takt umstellen, da hilft dann ein externer Takt. Was für einen Programmer benutzt Du denn? Du brauchst einen zuverlässigen Programmer mit eigenem MC, z.B. AVRISP MK2 oder STK500. Bei den LPT-Krücken braucht man sich nicht zu wundern, wenn ein Chip mal geht und ein anderer nicht. Darüber liest man hier fast täglich. Peter
Juhu, er lebt wieder: Externer Takt (4,5 V Rechteck 1,1 MHz) ! (Trotz LPT-Krücke mit 74HCT244) Die Fuses hatten einen komischen Wert angenommen, weder das was ich gesetzt hatte noch den Auslieferungszustand. Was kann denn Fuses verändern ? Funkwellen, radioaktive Strahlung, ESD ?
Die LPT Krücke soll es nicht richtig gemacht haben und deshalb ist später ein Teil der Fuses "verdampft" ?
Marc Mk schrieb: > Die LPT Krücke soll es nicht richtig gemacht haben und deshalb ist > später ein Teil der Fuses "verdampft" ? Immer dieser Quatsch... genauso liest man "täglich" das jemand sich den Chip mit nem Dragon oder sonstigen Programmer zerschossen hat. Haufigster Fehler ist und bleibt der Bedienfehler: - Fuses falsch interpretiert - Nicht ausgelesen vor dem schreiben - Nur mal schnell 'rumprobiert' - 10 Meter Kabel
Die Frage ist, was eine Fuse verändern kann, ohne Programmiergerät oder Kabel, ob so ein AVR Schaden nimmt, wenn man ihn, z.B. auf einen alten Fernseher legt. Oder Radioaktivität aussetzt. Ich hatte die Situation: Fuses richtig gesetzt, AVR funktioniert. Ca. 3 Wochen später hatten die Fuses einen komischen Wert angenommen und deswegen gab es keinen Clock mehr. Aber warum nur ? Und wie kann man das verhindern ?
@Marc: Sag mal, liest du eigentlich die dir gegebenen Antworten ? Erst hast du jeden Tip zur Fehlerfindung ignoriert und dann bist du der Meinung, dass wahrscheinlich Ausserirdische deinen AVR um-gefused haben. Dass der Fehler tatsächlich bei dir selbst (bzw. bei deiner Hardware) liegt, das ist wohl absolut ausgeschlossen ? Wie schon Läubi angedeutet hat: Häufigster Fehler ist und bleibt der Bedienerfehler. Glaubst du denn, dass so viele AVRs verbaut würden, wenn sie sich alle 3 Wochen selbst umprogrammieren ? Antwort auf Deine letzte Frage (Wie kann man das verhindern?): Indem man die Schuld nicht auf andere schiebt ! MfG Ulli
Falls ich jemanden verärgert haben sollte, tut mir das leid. Aber ich habe erst jetzt genug Geld zusammen gekriegt und einen Funktionsgenerator zu kaufen, um einen sauberen externen Takt geben zu können. Und damit hat es ja funktioniert, danke nochmals für den Hinweis. Ich bin doch auch AVR-Fan und habe schon viele verbaut, aber bisher hat sich noch keine Fuse verändert, da wollte ich wissen was dies ausgelöst haben könnte, ob es Exemplarstreuung, Zufall, eine Maschine in der Werkstatt nebenan, der neue Mobilfunkmast oder Erdstrahlung einen Einfluss darauf haben könnte. An der Hochschule hatten wir ein UV-Löschgerät und jemand hat berichtet, wie er EPROMs ohne Quarzglasfenster mit Röntgenstrahlung gelöscht hat, also so weit hergeholt ist meine Sorge nicht, dabei dachte eher an mangelnde Abschirmung (gegen Unbekannt) als an Aliens. Wenn es die billige Programmiereinrichtung ist (selber Schuld wer kein Geld hat), ob es dann helfen würde die Fuses mehrmals zu beschreiben ? Ich bin mir keiner Schuldzuweisung bewusst und vertrage auch Kritik, ich habe auch nicht gefragt wer meinen AVR kaputt gemacht hat, sondern ob sich bei jemanden auch schon mal Fuses verändert haben und welche Vorkehrungen möglich sind.
Auch wenn es (eigentlich) nichts (mehr) zur Sache tut: > Ohne Betriebsspannung sollten 5V an einem Port den AVR doch nicht > killen, oder ? Damit bist du auf jeden Fall ausserhalb der Absolute Maximum Ratings.
1 | Voltage on any Pin with respect to Ground ........... -0.5V to VCC+0.5V |
Denn wenn dein uC keine Betriebsspannung hat ist VCC = 0V. Und als Resultat bist du an diesem Pin über Vcc+0,5V. Und dann gilt
1 | *NOTICE: Stresses beyond those listed under “Absolute Maximum Ratings” |
2 | may cause permanent damage to the device. |
Hi, Marc Mk schrieb: > Ich bin mir keiner Schuldzuweisung bewusst und vertrage auch Kritik, ich > habe auch nicht gefragt wer meinen AVR kaputt gemacht hat, sondern ob > sich bei jemanden auch schon mal Fuses verändert haben und welche > Vorkehrungen möglich sind. ISt zwar kein AVR und betrifft auch nicht die Fuses, aber ich habe hier einen Pic"16c84" (Für U30 Generation: Das C ist korrekt!) mit noch extremeren verhalten. Bei fast jedem Auslesen verändert sich der Inhalt von zwei Speicherzellen. (bzhw. merke es erst beim Auslesen) Wenn da ein Programm drin ist das bis in diese Speicherbereiche kommt, dann funktioniert das auch nicht mehr. ISt das Programm kleiner oder mittels ORG der Bereich ausgeklammert so ist alles in Butter... Ob das nun aber ein Defekt ist der schon immer so war, oder ob das irgendwann mal aufgrund äusserer Einflüsse (damit meine ich ggf. auch meinereiner) entstanden ist, das weiß ich nicht. Der war jahrelang in einer einfachen Steuerung mit minimalprogramm eingesetzt die ich wärend meiner Lehrzeit (um 98) aufgebaut habe. Vor ca. vier Jahren brauchte ich den dann kurzfristig für etwas anderes, hatte gerade nichts besseres zur Hand und habe den genommen... Nach endlosen Probieren habe ich dann diesen Fehler gefunden! Von allen PICs die ich im Laufe meiner Ausbildung/Studium/Berufslebens in der hand hatte (>10K pcs) ist das aber der einzige der mit so einem Fehler aufgefallen ist. (natürlich gab es auch weitere defekte Pics, passiert im Bastlerleben nun einmal, aber das war immer etwas anderes) Ach Ja: Röntgenstrahlung bzw. Radioaktivität allgemein KANN Speicherzellen löschen. HAt zum beispiel bei den Aufräumarbeiten in Tschernobyl massiv für Probleme gesorgt (-Ja, die Russen habe zuerst Roboter/ferngesteuerte MAschinen für bestimmte Aufräumarbeiten einsetzen wollen bevor die massenhaft Personen "verheizt" haben. Die Dinger sind nur leider alle innerhalb von Minuten ausgefallen sobald sie im "heißen" Bereich waren) Ob man damit allerdings tatsächlich "halbwegs" zuverlässig OTP Proms wiederverwendbar machen könnte kann ich aber nicht sagen. Theoretisch sicherlich, aber ob in der Realität nicht noch andere Effekte, die zur Zerstörung des Chips führen würden, auftreten weiß ich nicht (mehr). Die entsprechenden Grundlagenvorlesungen sind einfach zu lange her... Gruß Carsten
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.