Unfreiwillige Sterbehilfe für den Atmega328P?

[Matsch]

Ich habe eine ganze Reihe von Selbstbau-Geräten unterschiedlichen Typs, doch in letzter Zeit hatte ich zunehmend Probleme mit dem Flashen und der Monitorausgabe per FTDI und IDE 2.3.2.
Das äußerte sich darin, dass bereits in der Monitoransicht vermehrt in ansonsten korrekten Zeichenausgaben plötzlich eine Reihe kryptischer Zeichen eingeschoben war. Offensichtlich lag eine Kommunikationsstörung der seriellen Verbindung vor, die Daten konnten zeitweise nicht mehr korrekt erkannt bzw. interpretiert werden. Es sah abschnittsweise so aus, wie es bei inkorrekter Baudrate aussieht.
Ich habe viel ausprobiert, per ISP war stets ein sauberes Flashen möglich, per FTDI aber nicht.
Irgendwann war ich der Meinung, das kann doch nur noch am FTDI-Adapter liegen. Also neuen bestellt und benutzt: Pustekuchen, gleiches Ergebnis! Letztlich habe ich den Atmega328P gewechselt - und alles funktionierte wieder.
Na gut, kann ja mal passieren.

Bald danach wieder das gleiche Erscheinungsbild an einem ganz anderen Projekt! Wieder half der Tausch des Atmega. Hmm, fehlerhafte Charge? Immer funktionieren die Dinger eine geraume Zeit, bis irgendwann die serielle Kommunikation gestört wird, aber eben nicht grundsätzlich versagt. Oft ist es so, dass sich der Chip schreiben läßt, aber die anschließende Verifizierung sofort fehlschlägt. Trotzdem arbeitet das Gerät anscheinend wie gewollt, es scheint der neu geflashte Sketch wirklich drauf zu sein. Einzig die serielle Schnittstelle macht Probleme.

Ich habe momentan nur eine Erklärung:
Da das Gerät selbst eine 3,3 V Speisung besitzt, habe ich die Brücke zur Auswahl der Betriebsspannung auf dem FTDI entfernt, damit die Stromversorgungen nicht gegeneinander arbeiten.
Vermutlich war das aber kontraproduktiv. Steckt man der FTDI-Adapter nun als erstes an USB an, bevor die Gerätespeisung aktiviert wird, so kommt es wohl zu einem Stromfluß aus den Ausgängen des FTDI in die seriellen Eingänge des stromlosen Atmega. Zwar besitzen die ja Schutzdioden, aber ich vermute, dass auf diese Weise vor allem der serielle Ausgang des Atmega auf Dauer Schaden nimmt. Jedenfalls ist das meine einzige Erklärung, warum ich mir schon 2 Atmegas auf unverständliche Weise zerschossen habe.
Zukünftig werde ich lieber die Stromversorgungen gegeneinander arbeiten lassen, damit keiner der Kommunikationspartner im Einsatzfall stromlos sein kann.
Vielleicht hat ja schon der eine oder andere gleiches erlebt und/oder eine andere Erklärung dafür?

[HMSteve]

Habe das so noch nicht erlebt und wuerde auch nicht die Spannungsversorgungen gleichzeitig nutzen, also entweder Schaltung regulaer gespeist oder ueber FTDI-Adapter. Beschaedigung der Ausgaenge halte ich aber fuer unwahrscheinlich.
Laufen Deine Problemkandidaten mit internem Takt oder mit Quarz? Ich hatte waehrend der Chipkrise selbst diverse 328p aus fernoestlicher Quelle mit grob falschem internen Oszillatortakt, den ich per individuellen OSCCal-Wert im Bootloader hinbiegen musste. Das koennte Deine Beobachtungen erklaeren. Wenn interner Takt und/oder dubiose Herkunft, wuerde ich den Takt mal per Fuse an BO ausgeben lassen und da messen. Vielleicht koennen chinesische Chips ja besonders rasant altern?

Viele Gruesse,
Stephan

[Matsch]

Ja, laufen auf internem Takt und ich hatte auch daran gedacht, dass der Takt daneben liegt. Konnte mir allerdings auch nicht vorstellen, dass der so weit weg liegt, dass das Toleranzfenster der seriellen Übertragung überschritten wird.
Rein äußerlich sehen sie eigentlich genauso aus wie die Originale, sind auch nicht in China gekauft (können aber natürlich trotzdem aus solchen Quellen stammen). Könnte auch die Zeit des Anfangs der Chipkrise gewesen sein. Leider kann ich jetzt nicht mehr nachvollziehen, ob beide Exemplare aus der gleichen Lieferung waren. Der neue IC hat aber einen anderen Aufdruck. Aber in einem weiteren solchen Fall werde ich tatsächlich mal den Takt nachmessen. Driftet der wirklich über die Zeit so sehr weg?
Oft war es so, dass der allererste Versuch nach dem Anstecken noch korrekt funktioniert hat, der zweite nur Minuten später nicht mehr. Könnte natürlich auch an einem Taktdrift liegen.
Vielleicht doch ratsam, mit 8 MHz-Resonator zu arbeiten. Eine Kostenfrage sollte es nicht sein und eine Platzfrage ist es nur manchmal.

[stan23]

Sowas habe ich bisher nicht erlebt.
Meistens versorge ich über den FTDI-Adapter, aber manchmal auch mit FTDI und ISP-Adapter gleichzeitig, wenn der Strom nicht ausreicht.
Oder mit dem Labornetzteil parallel dazu.

per ISP war stets ein sauberes Flashen möglich, per FTDI aber nicht.

Das ist klar, weil beim Flachen per ISP der Programme direkt per SPI in den Speicher schreibt. Da ist nur wichtig dass der SPI-Takt kleiner (als die Hälfte?) des Prozessortakts ist.

Steckt man der FTDI-Adapter nun als erstes an USB an, bevor die Gerätespeisung aktiviert wird, so kommt es wohl zu einem Stromfluß aus den Ausgängen des FTDI in die seriellen Eingänge des stromlosen Atmega. Zwar besitzen die ja Schutzdioden

Die UART-Pins des FT232R können nur max. 3 mA sourcen. Die sollten über die ESD-Dioden an den ATmega-IO abfließen ohne die Padstruktur zu zerstören, denke ich.

Könnte auch die Zeit des Anfangs der Chipkrise gewesen sein.

Möglicherweise wurden damals Samples verkauft die eigentlich aussortiert werden sollten?

[Matsch]

Die UART-Pins des FT232R können nur max. 3 mA sourcen. Die sollten über die ESD-Dioden an den ATmega-IO abfließen ohne die Padstruktur zu zerstören, denke ich.

max. 5 mA bei Vcc=0 und max. 1 mA bei Vcc=5V.


Das SPI-Flashen habe ich nur erwähnt um zu sagen, dass es so aussieht, als wäre der Chip ansonsten vollkommen funktionsfähig, lediglich die serielle Kommunikation ist die einzige bekannte Funktion, die nicht sicher geht. Die Taktfrequenz zu messen habe ich leider nicht gemacht und kann es jetzt nicht mehr. Aber vielleicht zeigen ja noch andere Exemplare im Laufe der Zeit gleiche Ausfälle.
Die beiden Ausfälle bei mir traten bei 2 ganz verschiedenen Projekten auf, beide mit internem Takt und könnten auch zeitlich nahe beieinander bestückt worden sein.

Dass der interne Takt keine gute Zeitbasis ist, ist ja klar, ich bin aber davon ausgegangen, dass die Abweichungen nie so groß sind, dass dadurch die Kommunikation per FTDI gestört sein könnte. Aber vielleicht hast du ja Recht:

Möglicherweise wurden damals Samples verkauft die eigentlich aussortiert werden sollten?

[TomMajor]

ich würde auch ähnlich wie HMSteve eher den internen RC Takt vermuten als Schuldigen.

Der int. RC Oscillator hat mehr oder weniger starke Abhängigkeiten zu Temperatur und Betriebsspannung, siehe Bild.

Ich kann z.B. meistens nicht seriell über Bootloader flashen wenn ich ein Gerät mit 2x NiMH Akkus (2,4V) habe, dann ist die Baudrate meist außerhalb der Toleranz.

[Matsch]

So langsam glaube ich auch, dass der wahrscheinliche Grund eher in der Taktabweichung zu finden ist.
Ich setze jetzt nur noch den 328PB ein - und mit Keramikresonator .

[dondaik]

sowas wird bei tiny als mögliche "totesursache" in einigen filmchen bei YT genannt ....

[Matsch]

Welches "sowas"?

[dondaik]

die möglichkeit des todes durch ein problem bei /mit den frequenzen ... wie gerade beschrieben wurde