Hallo, ich stehe ein wenig auf dem Schlauch was mein Problem betrifft. Ich programmiere mit einem Dragon oder ST500-Klon meine ATMEGA32A µC seit Jahren erfolgreich. Jetzt, also seit heute, habe ich das Problem dass er Flasht, dann prüft und alles okay findet. Fuses sind natürlich vorher gesetzt worden. Danach ist der Chip aber nichtmehr ansprechbar.... Lesecode bei der Signatur 0x00 0x01 0x02 - also keine Kommunikation. Nach unterbrechen der VCC und wiedereinschalten geht es genau 1 mal anzusprechen. das aufgespielte Programm bleibt beim Bootscreen auf dem angeschlossenen LCD stehen. In der Boardserie ist überall der gleiche µC mit dem selben Produktionscode verbaut, dass ich also ein Fake habe ist sehr unwarscheinlich, denn die anderen Boards haben bisher immer tadellos funktioniert. Mache ich ein Chiperase direkt nach einschalten der VCC kann ich ihn so lange ansprechen, solange ich ihn nicht programmiert habe. Wo könnte denn der Fehler liegen? Gruß Anselm
Du hast nur einen Chip getestet? Oder mehrere? Einer geht auch mal kaputt, auch teilweise, so dass man meint, er lebt noch.. :-)
Nutzt du einen Quarz für den Takt? Eventuell hier falsche Kondensatoren erwischt oder einen Quarz mit Macke?
Wie es so ist, nachdem ich 20Minuten die Frage hier getippt hatte und noch am suchen war, 5Minuten nach dem Absenden habe ich den Fehler selbst gefunden. Schuld war der 2te µC der fälschlicherweise den WDT enabled hatte, dadurch hat er den Main mit Resettet.. so kann der natürlich nix machen ;) Merke: machst du es richtg, funktioniert es sogar! Gruß Anselm und Danke für Eure Anteilnahme ;)
Gast
#4362995
Anselm 6. schrieb: > Nach unterbrechen der VCC und wiedereinschalten geht es genau 1 mal > anzusprechen. In diesem Nebensatz hast du höchstwahrscheinlich genau das Problem definiert. Es ist bei so einem Fehlerbild hochwahrscheinlich, dass der Code (natürlich ungewollt) einen illegalen Hardwarezustand herbeiführt. Da normaler Code das natürlich nicht absichtlich macht, ist es wiederum hochwahrscheinlich, dass abstürzender Code das tut. Also muss man verhindern, dass der Code bei Verlust der Betriebsspannung überhaupt die Chance bekommt, abzustürzen. Das tut man, indem man den genau für diesen Zweck vorhandenen "brown out detector" sinnvoll benutzt. Also indem man ihn aktiviert und mit einem bezüglich der Umgebung der konkreten Anwendung sinnvollen Schwellwert ausstattet. Beides tut man über die zielführende Programmierung der entsprechenden Fuses. Und (fast) alles Wissenswerte darüber steht (wie immer) im Datenblatt...
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.