Forum: Mikrocontroller und Digitale Elektronik Atmega32U4 USART TX stoppt plötzlich


von 900ss (900ss)


Lesenswert?

Hallo,

habe ein recht schräges Problem mit einem ATMEGA32U4.

Ich übertrage eine Weile Daten über den USART, sendent wie empfangend. 
Nach einer Weile sendet der USART plötzlich nichts mehr.

Die USB-serielle des ATMEGAs arbeitet weiter. Die verwende ich mit einem 
Terminal als DEBUG-Schnittstelle.

Ich habe damit nachdem die Übertragung abbricht, die USART-Register 
gedumpt.

UCSR1A: 0x62
UCSR1B: 0x98
UCSR1C: 0x06
UCSR1D: 0x00
UBRR1: 0x0008

Das sieht richtig aus wenn ich mich nicht irre. Genauso sieht es auch 
aus nach power on, wenn noch alles funktioniert. Wenn ich direkt auf das 
Register UDR1 schreibe, geht das Zeichen nicht raus. Mit Scope direkt am 
TX-Pin geprüft.

Der Registerdump sieht danach genauso aus.

Dann habe ich die Register alle auf 0 gesetzt und wieder so 
initialisiert, wie oben gedump. Dann sieht der Dump so aus.

DBG: usbTask(): UCSR1A: 0x22
DBG: usbTask(): UCSR1B: 0x98
DBG: usbTask(): UCSR1C: 0x06
DBG: usbTask(): UCSR1D: 0x00
DBG: usbTask(): UBRR1: 0x0008

Jetzt schreibe ich auf UDR1 (also das Datenregister). Der USART sendet 
weiter nichts. Das mein Scope richtig angeschlossen ist, habe ich 
geprüft als der Uart moch sendete, also nach power on. Der Registerdump 
sieht dann wieder so aus wie oben, also TCXn ändert sich. Aber gesendet 
wird nichts.

Alles andere läuft korrekt. Die USB-serielle und auch der I2C-Slave.

Was kann dazu führen, dass der USART sich weigert, ein Zeichen zu 
senden. HW-Flowcontrol ist ja aus, TX ist enabled (siehe Registerdump).

Ich bin ratlos :-)
Danke für sachdienliche Hinweise ;-)

900ss

: Bearbeitet durch User
von Thomas W. (diddl)


Lesenswert?

Hmmm, keine Ahnung wo genau dein Problem liegt.


Jedenfalls kann ich dir mit Bestimmtheit sagen, dass es kein 
grundsätzliches problem ist.

Diesen Controller setze ich sehr intensiv ein und hatte noch niemals ein 
Problem mit dem USART. Das Teil ist sowas von stabil.

Stützkondensatoren sind eh da?
Und nah genug am Controller?

von Volker B. (Firma: L-E-A) (vobs)


Lesenswert?

900ss D. schrieb:

> Ich übertrage eine Weile Daten über den USART, sendent wie empfangend.
> Nach einer Weile sendet der USART plötzlich nichts mehr.

Versehentlich Hardware Flow Control aktiviert?

USART Control and Status Register – UCSRnD

• Bits 1 – CTSEN: UART CTS Signal Enable
Set this bit by firmware to enable the transmission flow control signal 
(CTS). Transmission will be enabled only if CTS input = 0. Clear this 
bit to disable the transmission flow control signal. Transmission will 
occur without hardware condition. Data Direction Register bit must be 
correctly clear to enable the pin as an input.

Grüßle,
Volker.

von Thomas W. (diddl)


Lesenswert?

Er schreibt doch, dass UCSR1D gleich 0 ist ...

Also KEIN Hardware Flow Control

von Eric B. (beric)


Lesenswert?

Sieht für mich aus nach einem Software-Problem. Aber ohne weiter Angaben 
dazu kann man nur raten. Versuch das Problem weiter einzukreisen: 
Programm schrittweise reduzieren bis das Problem nicht mehr auftaucht 
oder das Aha-Erlebnis sich ereignet :-)

von hmmm (Gast)


Lesenswert?

TXD Port Pin nicht mehr output sondern input?

von c-hater (Gast)


Lesenswert?

hmmm schrieb:

> TXD Port Pin nicht mehr output sondern input?

Kann nicht sein, da TXEn offensichtlich gesetzt ist und TXEn die 
Einstellung, die man via DDR-Register für den Pin machen könnte, 
schlicht immer und unter allen Umständen "überstimmt".

Was allerdings denkbar wäre: der Fehler liegt garnicht beim Sender.

Ein "Kurzer" gegen eine Versorgungsleitung oder ein fälschlicherweise 
als Ausgang geschalteter Rx-Pin des Empfängers, kann so ein UART-Signal 
ziemlich leicht zur Fast-Flatline werden lassen.

Ich würde mal auf einen "fliegenden" Aufbau tippen (Breadboard oder 
irgendso einen Dreck) und irgendwas, was unter bestimmten Umständen 
einen Kurzen produziert, z.B. ein rumrollendes Stückchen Draht oder ein 
loses Zinnkügelchen.

Um das Szenario auszuschließen, lötete man einfach mal den TX-Pin ab, 
isoliert ihn vom Rest der Schaltung und mißt dann noch einmal. Ich würde 
fast wetten, dass das Senden dann nicht mehr abbricht...

von 900ss (900ss)


Lesenswert?

Softwareproblem will ich ja nicht ausschließen,  allerdings die 
Neuinitialisierung und danach das Schreiben ins  Datenregister sollte 
etwas auf der TX-LEITUNG produzieren.

Ich dachte jetzt auch, HW-Flowcontrol ist aktiviert oder der TX-PIN ist 
als Eingang geschaltet. Laut Datenblatt kam das nicht sein da der TX 
enabled ist,  siehe Registerdump.

HW-Flowcontrol ist auch aus. Gibt es evtl. noch ein Register welches ich 
nicht kenne, was soetwas produziert? Ich hab im Datenblatt nichts 
gefunden.

Ja,  es ist ein fliegender Aufbau. Allerdings wird der nicht bewegt. 
Das liegt da ruhig auf dem Tisch.  Und wenn ich das dann mit Reset per 
Bootloader beheben kann ohne Powercycle oder die Schaltung zu bewegen, 
dann wird es kaum ein Kurzschluss sein. Denke ich...

Hmmmm....

von 900ss (900ss)


Lesenswert?

Ach ja,  das mit dem fälschlicherweise als Output geschalteten RX-PIN 
hatte ich auch im Verdacht.  Habe die Leitung dazwischen aufgetrennt und 
mit Steckverbinder verbunden. Als der Fehler auftrat, habe ich die 
Leitung aufgetrennt und dann gemessen und ins Datenregister geschrieben. 
Nichts!.....  :-/

von 900ss (900ss)


Lesenswert?

Die Auflösung des Rätsels gibt es jetzt auch.
Das Problem saß, wie kaum anders zu erwarten, vor dem Bildschirm. Es war 
kein SW-Fehler sondern doch ein Messfehler. Hatte das Scope am RX-Pin 
angeschlossen. Und dort kam plötzlich nichts mehr an, weil das 
angeschlossene Bluetoothmodul nach einer Weile dem Dienst verweigert. 
Das ist jetzt das eigentliche Problem.

Danke für euren "Beistand" ;-)

900ss

: Bearbeitet durch User
Bitte 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
Noch kein Account? Hier anmelden.