Hallo Zusammen, ich hab seit ein paar Tagen ein Problem. ich habe ein Programm auf einem ATMega 168A. Leider Blockiert dieses den µC nach ein paar läufen. Fuses habe ich zum Zeitpunkt des Blockierens keine geändert. Dies geschah bereits schoneinmal, bei einem ATMega48, aber da ich da gleichzeitig auch mit den Fuses rumprobierte, dachte ich ich hab ihn dabei blockiert. Nun hab ich eine Böse Vermutung. Das Programm schneidet UART Kommunikation mit, und schreibt sie ins EEPROM. Leider hatte meine Schreibroutine ein Problem, nämlich das ich mit einem Zähler die EEPROM Adresse hochgezählt hab, aber keine Stop-Bedingung für das Ende des EEPROM. Solang ich nur am Anfang des EEPROMS geschrieben hab, war auch alles ok. Ich konnte testen, und das Ergebnis problemlos auslesen. Heisst, ich hab fröhlich darüber hinaus geschrieben. Kann es sein das die Fuses, welche ja auch nur Speicherzellen sind, im EEPROM Bereich lieben, und ich die dadurch überschrieben hab? Hab nur noch einen funktionierenden µC da, mag es jetzt also nicht ausprobieren wollen. Und 12V Brennen kann ich noch nicht, der Dragon ist noch in der Post. Was denkt Ihr zu meiner Theorie?
Fuses können nicht zur Laufzeit geändert werden, sonst wären es keine Fuses. Das Schreiben in undefinierte Speicherbereiche könnte I/O-Register verbiegen, die für den Controller wichtig sind. Deshalb wird das Programm den Dienst einstellen. Läuft denn der Controller wieder, wenn Du die Spannung kurz aus- und wieder einschaltest?
Hi, ist recht unwahrscheinlich. Soweit ich weiss, lassen sich Fuses aus dem Inneren des Controllers, also per Programm nicht ändern. Fuses mit dem Programmer mal ausgelesen? Schönen Tag noch, Thomas
Das ist es ja. Das Programm ist nie bgestürzt. Ich kann nur mit dem Programmer nicht mehr drauf zugreifen, und Reset geht nicht mehr. Beim geblockten anderen Geblocktenb µC das selbe: Programm geht, Reset tot, kein Zugriff per Programmer. Und jetzt glaub ich meine eigene Theorie auch nicht mehr. Es ist wieder passiert. Diesmal beim programmieren selbst. Erst gehts, dann eine kleine Änderung am Programm, neu aufspielen, noch ne Idee haben, nochmal compilieren und beim Aufspielen: BAMM! Zugriffsverlust während des aufspielens. Das alte Programm tut weiter! Langsam hab ich den Verdacht meine Schaltung macht da was kaputt. Bin grad dabei nachzuschauen Ob es was zu beachten gibt, wenn man den SP direkt an eine aufgebaute Schaltung nschliesst. Hab bisher die entsprechenden Pins direkt mit den Eingängen am Steckbrett verbunden. Einzige Doppelbelegung ist Reset, aber der hängt lose. Steck ich ja nurkurz zum Reseten rein. Ich mal mal die Schaltung runter. Vlt fällt dann dazu jemandem was auf. Ach ja, Programmer ist ein Diamex AllAVR
> Nun hab ich eine Böse Vermutung. > > Kann es sein das die Fuses, welche ja auch nur Speicherzellen sind, im > EEPROM Bereich lieben, und ich die dadurch überschrieben hab? Hmm. Theoretisch wäre das durchaus denkbar. ich würde es also keinesfalls ausschließen wollen. Allerdings habe ich da aktuell kein Problem mit und überlasse die Forschungen lieber dir. Ich wäre aber durchaus an einem Bericht über die Ergebnisse deiner Forschungen interessiert. Mich interessieren dabei weniger die Lockbits als vielmehr der Rest der Fuses. Wenn die sich zur Laufzeit von der Software überschreiben ließen, würde das einige hochinteressante Anwendungen sozusagen "freischalten".
...zum Beispiel, wenn du dir den Reset-PIN wegprogrammiert hast, dann geht natürlich kein Reset mehr und auch kein Programmieren. Nur so eine Idee...
Angehängte Dateien:
-
Schaltung.png
11 KB
So, also hab jetzt mal den Schaltplan gemalt. Der Wiederstand an INT0 ist 10k, die Kondensatoren am Oszillator sind 22pf. Die Anschlüsse für Miso/Mosi/Sck/Rst gehen direkt auf den Programmer, Rx/Tx auf Tx/Rx vom ETRX357 Board. Dieses hat auch eine eigene getrennte Stromversorgung. Verhalten tut sichalles als ob ich RstDisable Fuse gesetzt hätte, hab ich aber nicht (wollentlich und wissentlich). Was ich gemacht hab ist folgendes: an Rx nd Tx hab ich ein Oszi hängen, bei Auslösung von Int0 geht ein Befehl an den ETRX357 und die Antwort wird ins EEPROM geschrieben. Beim Missglückten Programmieren befand de µC sich in der Schaltung.
Hmm, soweit war ich ja auch schon ;) Nur, wieso, Mr. Fuse? Any Idea?
Mach da erstmal einen 10k - 22k pullup an die Reset Leitung. Wenn die quer über die ganze Platine geht, kann es schon sein, das die sich Störungen von Nachbarleitungen einfängt.
Mitko Rürup schrieb: > So, also hab jetzt mal den Schaltplan gemalt. Da wird einem ja ganz wuschig im Kopf, wenn man den Netzteilteil ansieht. Wo ist denn da oben und unter. Dein komisches Verhalten liegt vielleicht daran, dass du den µC nur halb angeschlossen hast. Mindesten Pin 20 und 22 gehören noch an die Versorgung. Außerdem fehlt mindestens ein 100nF Abblockkondensator an jedem VCC-Anschluß des µC. Kein Wunder, dass der sich mackig benimmt. Und was soll die Sicherung beim SW2? Und was ist mit U$2? Bekommt das keine Versorgungsspannung? Oder zieht es die über PB1 und PB2 bei passenden Logikpegeln ;-(
Die Beschaltung des /RESET ist falsch. Der Schalter muss nach GND und ein Pullup-Widerstand (ca. 10k-22k) nach VCC. Der Reset ist active LOW, wie man am / erkennt.
..ausserdem sind AVcc und GND (sowie ARef) nicht adäquat beschaltet.
Thomas schrieb: > Mitko Rürup schrieb: >> So, also hab jetzt mal den Schaltplan gemalt. > > Da wird einem ja ganz wuschig im Kopf, wenn man den Netzteilteil > ansieht. Wo ist denn da oben und unter. > Oben ist Oben. Ist genau in der Reihenfolge auf dem STeckbrett aufgebaut. Sind deshalb zwei Spannungsregler, damit ich bei Bedarf nch eine weitere Spannung zur Verfügung habe. > Dein komisches Verhalten liegt vielleicht daran, dass du den µC nur halb > angeschlossen hast. Mindesten Pin 20 und 22 gehören noch an die > Versorgung. Außerdem fehlt mindestens ein 100nF Abblockkondensator an > jedem VCC-Anschluß des µC. Kein Wunder, dass der sich mackig benimmt. Ok, wird so eingebaut. Dachte bisher der zweite VCC AREF und der zweite GND sind nur notwendig wenn man die ADC benutzt. > > Und was soll die Sicherung beim SW2? Da hab ich aus versehen ne Linie Durch nen Wiederstand gezogen. Ist ein 10k als Pullup gedacht für INT0. > > Und was ist mit U$2? Bekommt das keine Versorgungsspannung? > Oder zieht es die über PB1 und PB2 bei passenden Logikpegeln ;-( Das ist der ETRX357. Der hat noch seine eigene Stromversorgung, unabhängig aus einem Labornetzteil.
Ok, hab jetzt alles nach Euren Anregungen umgebaut. Da die µC ja leider geblockt sind kann ich jetzt noch nicht direkt schaub ob das seltsame Verhalten verschwunden ist. Aber schonmal Danke für Euren Support.
SW2 soll aber nicht eine Taste sein, die man per Int0 einliest ?
Mitko Rürup schrieb: > Das ist der ETRX357. Der hat noch seine eigene Stromversorgung, > unabhängig aus einem Labornetzteil. Dann musst Du aber aufpassen, dass immer beide ICs versorgt sind! Sonst kann es Spannungen und Querströme an den Ports geben, die die "Absolute Maximum Ratings" überschreiten. Die Folge kann ein Latch-Up oder sogar die Zerstörung der Bauteile sein. Also: Gemeinsam versorgen oder mindesten einen Strombegrenzungswiderstand in die Leitungen PB1 / PB2. Gruß Dietrich
Dietrich L. schrieb: > Mitko Rürup schrieb: >> Das ist der ETRX357. Der hat noch seine eigene Stromversorgung, >> unabhängig aus einem Labornetzteil. > > Dann musst Du aber aufpassen, dass immer beide ICs versorgt sind! > Sonst kann es Spannungen und Querströme an den Ports geben, die die > "Absolute Maximum Ratings" überschreiten. Die Folge kann ein Latch-Up > oder sogar die Zerstörung der Bauteile sein. Ok, mach ich heut Abned dann mal. Wie genau kommt es zu diesen falschen Spannungen und Querströmen? Kann ich doch bestimmt irgendwo nachlesen? > Also: Gemeinsam versorgen oder mindesten einen > Strombegrenzungswiderstand in die Leitungen PB1 / PB2. Gemeinsam Versorgen stand ehschon auf dem Plan. Wird nachgerüstet. Danke für die Warnungen! Gruß, Mitko
Грясивыи цомби schrieb: > SW2 soll aber nicht eine Taste sein, die man per Int0 einliest ? Doch, schon. Nicht schön, aber tut erstmal den Job. Soll ja nur eine testweise Übertragung auf Tastendruck auslösen.
Mindestens die Masse sollte gemeinsam sein, damit die Schaltung ein gemeinsames Bezugspotential hat.
Mitko Rürup schrieb: > Wie genau kommt es zu diesen falschen Spannungen und Querströmen? Beispiel (ohne Kontrolle, ob das eine sinnvolle Betriebsart ist): - Der µC ist versorgt, der ETRX357 nicht. - Der µC steuert über PD0 und/oder PD1 den ETRX357 an und will eine "1" (+5V) ausgeben. - die Bedingung laut "Absolute Maximum Ratings": Voltage on any I/O: -0.3Vdc to VCC +0.3Vdc ist nicht erfüllt: Bei Vcc = 0 darf am Eingang max. 0,3V anliegen - Es fließt ein Strom über die Schutz- oder Substratdioden in die Eingänge des ETRX357. (Hierüber habe ich im Datenblatt jetzt nichts gefunden, das ist aber meistens so). - Bei Vcc + 0,3V ist der Strom an den Eingängen klein genug, daher ist das erlaubt. - Ein Längswiderstand begrenzt den Strom. - Den max. erlaubten Strom habe ich beim ETRX357 jetzt nicht gefunden, aber üblicherweise sind diese Ströme im Bereich von 1...10mA. In jedem Fall ist das besser als keine Begrenzung, wenn auch ohne Garantie. - Was beim Überschreiten des Stroms jetzt genau passiert, ist auch nicht spezifiziert. Es kann sein: Zerstörung des Eingangs oder Latch-Up-Effekt (dann muss Vcc aber schon "etwas" anliegen). Alternative zum Widerstand (das ist dann "sauber", da dann wirklich kein Strom in den Eingang fließt): - passendes Interface-IC, die höhere Spannungen am Eingang verträgt - Transistor mit Ziehwiderstand nach Vcc des Partners (open-collector-Schaltung). Gruß Dietrich
Danke Dieter, klasse Erklärung. Ok, dann quäl ich die beiden seit Tagen ganz arg. Muss ich nacher sofort umbauen. Die Transistorlösung klingt mir da sehr sinnvoll. Hab die Daten im Datenblatt gefunden. Ok, muss ich also mal durchrechnen, da in die Schaltung ja noch ein Bauteil kommt das 5V braucht.
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.