Warum verhält sich mein AVR seltsam (Resets, Datenkorruption), wenn er ein paar Bytes auf dem UART empfängt?

Ich habe einen ATmega644, der über den UART mit einem anderen Gerät verbunden ist. Nach dem Empfang einiger Zeichen auf dem UART wird das Gerät zurückgesetzt und / oder verhält sich seltsam. Einige Beispiele für dieses Verhalten:

  • Code, bevor die Hauptschleife erneut ausgeführt wird, aber MCUSR ist 0 (dh kein "echter" Reset)
  • Code innerhalb der Hauptschleife wird ausgeführt, obwohl die mit den Eingängen verbundenen Schalter nicht gedrückt wurden (Pullups sind richtig konfiguriert).
  • Manchmal hängt sich die MCU einfach auf
  • Manchmal fungieren Ports, die nicht als Ausgänge konfiguriert wurden, als Ausgänge (zB angeschlossene LEDs leuchten auf, obwohl der DDR für diesen Port 0 ist).

Das Gerät verwendet einen externen 18,432-MHz-Quarz und der UART ist auf 19200 Baud eingestellt. Es wird mit 5V betrieben; Der RX-Pin ist mit einem 3V3-RPi verbunden.

Antworten (4)

Auch wenn das Problem bei diesem speziellen Setup etwas anderes war (wie in einer anderen Antwort hervorgehoben), besteht ein weiterer häufiger Grund darin, dass der Controller in Bezug auf die Vcc-VS-Taktgeschwindigkeit außerhalb des "sicheren Betriebsbereichs" betrieben wird.

atmega644 Vcc VS Taktgeschwindigkeit

Mit 18,432 MHz Taktrate würde das Gerät mindestens etwa 4,2 V benötigen, um richtig zu funktionieren.

Intermittierendes Verhalten ist oft das Ergebnis fehlender oder unzureichender Leistungsentkopplungskappen in der Nähe Ihres Controllers? Als Faustregel gilt: 100 nF für jeden Pin mit der Bezeichnung Vcc, so nah wie möglich an den Power-Pins des Controllers. Wenn Sie schon dabei sind, ist es immer gut, Ihre Stromschienen mit einem Voltmeter (und einem Oszilloskop, falls verfügbar) zu überprüfen.

Dies wird normalerweise durch falsche CKSEL- Sicherungen verursacht. Der ATmega644 muss so konfiguriert werden, dass er den Quarz im "Full Swing Oscillator"-Modus für Taktraten über 16 MHz antreibt; Für bestimmte andere MCUs scheint diese Option ein separates Sicherungsbit namens CKOPT oder CLKOPT zu sein

In meinem Fall hat es die Verwendung von CKSEL = 0111 behoben, aber der beste Weg, die richtigen Sicherungen herauszufinden, ist die Verwendung eines Sicherungsrechners und die Überprüfung der Ergebnisse anhand des Datenblatts, bevor sie geschrieben werden.

Ist es möglich, dass Sie den RS232-Port des Computers direkt mit den UART-Pins der ATmega MCU verbunden haben?

Die + und - Spannungsschwankungen des RS232-Ports würden den ordnungsgemäßen Betrieb des MCU-Siliziums verheeren. Diese Verwüstung könnte zu einem der von Ihnen beschriebenen Fehlersymptome führen.

Normalerweise werden die Leitungen eines RS232-Ports eines PC-Computers durch einen Spannungspegelumsetzer gepuffert, der sie in Spannungspegel umwandelt, die mit der MCU kompatibel sind. Wenn Sie dies nicht eingerichtet haben, ist eine Änderung Ihrer Einrichtung erforderlich.

Das andere Gerät ist ein Himbeer-Pi, der 3,3 V verwendet, also nein, das war nicht das Problem. Aber würden die ~ 15 V den AVR nicht einfach braten, anstatt ihn nur dazu zu bringen, sich seltsam zu verhalten? Wie auch immer, ich habe diese Frage hauptsächlich für den Fall gepostet, dass jemand anderes das gleiche Problem hat, damit er nicht Stunden damit verschwendet, es zu debuggen (weshalb ich auch sofort die Antwort gepostet habe).
@ThiefMaster - Hehe, ich habe nicht bemerkt, dass Sie sowohl Fragesteller als auch Antworter waren. RS232-Ports verwendeten selten 15 V. Stattdessen verwendete das Original +/-12V. Die aktuelle Technologie verwendet hauptsächlich Ladungspumpen-Transceiver, die Signale im Bereich von +/-5 V bis +/-9 V erzeugen. Man weiß nie, ob ein höheres Spannungssignal einen IC völlig durchbrennt oder ob es nur ein anormales Verhalten hervorrufen kann. Oft können die seltsamen Symptome eine Zeit lang anhalten und dann frittiert das Teil nach einer Zeit anhaltender Folter durch die Hochspannung.