ATmega644PA empfängt auf USART1 nur 0-Bytes nach 2 Min

> FE1 kommt daher weil auf dem Bus einige Geräte anstelle
> 2 Stop-Bits nur eines senden.
Das glaube ich nicht, aus dem Datenblatt zu FEn:
"This bit is set if the next character in the receive buffer had a Frame 
Error when received. I.e., when the first stop bit of the next character 
in the receive buffer is zero."

> IMHO kann das ignoriert werden.
M.E. ist das FE1 ein wichtiger Fingerzeig.

Zunächst Danke für Eure Antworten!

@Lothar:

So wird das kontrolliert:

1

uint8_t data, stat;

2

3

stat = UCSR1A;

4

data = UDR1;

5

6

UDR0 = data;

7

8

// hier werte ich die Fehlerflags aus

9

// aktuell nur DOR1

USART0 läuft mit 115200bps, USART1 mit 9600
Von daher ist "UDR0 = data" so machbar ohne groß zu warten.
Am PC lasse ich mir die empfangenen Daten als Hex ausgeben.

@S. Landoldt:

Beim letzten Test habe ich vor dem Fehlerfall auf dem RS485 1247 
Telegramme (alle mit korrekter Prüfsumme usw.) erhalten. Darunter auch 
viele einzelne Bytes mit nur einem Stop-Bit.

Bisher hatte ich auf allen meinen Geräten den RS485 auf USART0 und nie 
ein ähnliches Problem gehabt. Den Code habe ich portiert und mehrfach im 
Editor und per grep auf der Konsole sichergestellt dass überall die 
richtigen Register verwendet werden.

FEn heißt, dass der Empfänger auf dem ersten (!) Stopbit eine Null 
sieht.

Lothar Miller schrieb:
> Wenn auf der Hardware die Signale tatsächlich am Pin ankommen
Die Betonung liegt auf 'am Pin'.

Guten Morgen,

auch ist zu überprüfen, ob man senden über Uart0 darf.

UCSR0A – USART Control and Status Register A
Bits:
RXC0 TXC0 UDRE0 FE0 DOR0 UPE0 U2X0 MPCM0

while ( (UCSR0A & (1<<UDRE0)) == 0  ) { }

Das zeigt dieses Codestück nicht.

1

uint8_t data, stat;

2

stat = UCSR1A;

3

data = UDR1;

4

UDR0 = data;

Man könnte nun entgegen, dass die beiden Uart mit unterschiedlicher 
Baudrate arbeiten, aber man weis halt nicht wirklich, ob der 
Senderegister von Uart0 bereit ist neue Daten aufzunehmen !

Erst dachte ich es werden sauber Sende- und Empfangspuffer (Fifo) für 
beide Uart genutzt, aber nein, das UartN-Handling ist unsauber in meinen 
Augen.

@Oliver:

UDRE0 könnte man abfragen, ja. Trotzdem kommt die ISR von USART1 knapp 
jede mS und dann hat USART0 schon längst alles im Hintergrund 
verschickt.
Es kommen ja auch alle 1247 Telegramme korrekt am PC an, nur dann nur 
noch Nuller.

@S. Landoldt:

FEn auf erstem Stopbit, richtig (gerade nachgelesen).
Die Ursache ist ein Gerät auf dem Bus was keine 2 Stopbits kann und das 
dann per 9-Bit Übertragung emuliert. Firmware ist nicht von mir und den 
Fehler kenne ich.
Gerät vom Bus abgeklemmt und siehe da - kein FE1 mehr.
Fehlerbild ist immernoch das gleiche. Gerade nach 700 Telegrammen.

> Die Betonung liegt auf 'am Pin'.

Nun, ich gehe davon aus dass die Lötstellen von der vorgefertigten 
Platine in Ordnung sind und eine Messung ausreicht um sicherzustellen 
dass die Bits aus Tatsächlich am Pin ankommen.
Nehmen wir den unwahrscheinlichen Fall dass die Verbindung nicht in 
Ordnung ist, dann kommen entweder zufällige Daten an oder gar nichts.

Im Rhythmus der der Telegramme wird die ISR von USART1 aufgerufen und 0 
aus UDR1 ausgelesen. Ohne dass überhaupt ein Takt am RXD1 anliegt würde 
das doch nicht passieren, oder?

Nachtrag:

Auf mehrfachen Wunsch und trotz meines besseren Wissens habe ich nun den 
Code wie folgt "sauber" abgeändert:

1

uint8_t data, stat;

2

stat = UCSR1A;

3

data = UDR1;

4

loop_until_bit_is_set(UCSR0A, UDRE0);

5

UDR0 = data;

Ergebnis: Bringt nix, gleiches Ergebnis - immernoch Nullen

Hallo Bernhard,

für mich, bzw. die Fehlersuche, machst Du noch zu viele Annahmen.
Ich habe gelernt noch nichts als gegeben aus zu gehen und selbst alle 
Verbindungen zu überprüfen und auch selbst für einen korrekten Code zu 
sorgen.

Kannst Du bitte eine abgespecktes Programm, das einen mögl. Fehler immer 
noch zeigt, bitte komplett einstellen ?

Mit komplett ist gemeint, dass unserer AVR Gcc diesen Quelltest auch 
übersetzt.

@Karl:

Danke für Deine Unterstützung.
In einer ISR mache ich ungern while Loops. Davor hatte ich ausgiebige 
Tests mit ner FIFO-Loop für USART0.
Um das Thema nicht allzu aufzublähen habe ich das weggelassen. 
Vielleicht war das ein Fehler, ist aber jetzt nicht wichtig.

Beispielcode: Ja, das ist das Ulitimo-Ratio - bisher will ich mir den 
Aufwand sparen.

Hat denn irgendjemand schonmal ein ähnliches Problem gehabt? Das wäre 
spannend zu wissen. Wenn nicht dann muss ich einfach weiter in der 
Software nach einer möglichen Ursache suchen.

Hallo Bernhard ,

ich will nicht überheblich klingen, Probleme sollte man immer im Code 
suchen.

Bei mir läuft Uart0 etc. immer problemlos.
Ich verwende immer für den Hardware-Uart eine RX-/TX-Fifo gestützte 
Implementierung.
Diese muss man nur einmalig richtig programmieren und kann sie dann als 
kleine Lib immer über ein Makefile und einer Inlcudedatei mit einbinden.

Und so könnte das für Uart0 aussehen:

Beitrag "AVR-GCC: UART mit FIFO"

Karl M. schrieb:
> ich will nicht überheblich klingen, Probleme sollte man immer im Code
> suchen.

Klingt aber falsch. Was ist, wenn der Fehler in der HW steckt. Nicht 
notwendigerweise im µC aber im sonstigen Azfbau?

@Peter:

Vielen Dank für den Tipp!
Das ist nämlich genau die Ursache für die Null-Bytes!
Das UBRR1L Register wird auf 0 gesetzt und damit wird das Start-Bit als 
Byte abgetastet!

Der Fehler lag natürlich auch in der Software - ein Copy-Paste Fehler in 
einem Array von verschiedenen Bus-Geschwindigkeiten war

1

{ .high = BAUD1_UBRR1H, .low = BAUD1_UBRR1H}

... sollte eigentlich heißen:

1

{ .high = BAUD1_UBRR1H, .low = BAUD1_UBRR1L}

Danke an alle für Eure Hilfe!

Das ist mir nicht klar, da sollte doch ein Frame-Error kommen. Wie passt 
das zu:

Bernhard schrieb:
> ... Firmware ist nicht von mir und den Fehler kenne ich.
> Gerät vom Bus abgeklemmt und siehe da - kein FE1 mehr.

@ S. Landoldt:

FE1 bei normaler Funktion - hatte ich möglichereweise missverständlich 
formuliert.

@ Oder Doch:

Zuerst 20MHz Quarz, während Fehlersuche gegen 14.7456MHz getauscht.
Daran lags sicher nicht :)


Wie gesagt - Problem ist jetzt gelöst - danke nochmal!