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
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?
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.
Er schreibt doch, dass UCSR1D gleich 0 ist ... Also KEIN Hardware Flow Control
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 :-)
Gast
#4869032
TXD Port Pin nicht mehr output sondern input?
Gast
#4869077
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...
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....
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!..... :-/
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