[BUG REPORT] Append stört Serport

Hallo AVRCO

Fehlerbeschreibung:
Es treten Empfangsfehler bei UART auf, wenn die Funktion Append verwendet wird.
Der Fehler tritt nur auf, wenn der erste Parameter von Append vom Typ char ist.
Wenn der Fehler auftritt, dann wurde ein falsches Zeichen empfangen.
Das falsch empfangene Zeichen ist nicht zufällig. Es hat den Wert vom Vorgängerzeichen.
Diese Erkenntnis nutzt das Demoprogramm aus, um fehlerhafte Zeichen zu erkennen.

Workaround:
Existiert. Append nicht verwenden oder den ersten Parameter nicht als char übergeben.

Hardware:
Atmega32 mit 8 MHz Crystal, 5V, Fuses: SPIEN + CKOPT + BODLEVEL + BODEN
PC mit Terminal Programm Hterm, ST232 an RX0 und TX0

Vorgang:
Hterm sendet alle 100ms '{123456789abcdefghijklmnopqrstuvwxyz}' zum atmega
Wenn ein fehlerhaftes Zeichen empfangen wurde, sendet atmega 'Error' zurück.

Hinweis:
Wir haben im Interrupt RXRDY den Registerinhalt von UDR über SPI ausgegeben.
Im Fehlerfall war schon der Registerinhalt falsch.

Hallo Rolf,

können die Empfangsfehler damit erklärt werden?

Bei Append(charX, PCstr) wird vor dem Unterprogrammaufruf der Inhalt von charX in das Register R23 und der Wert 1 in das Register R22 geschrieben.
R22/R23 stellen somit einen string der Länge 1 dar.
Der Funktion Append scheint das nicht zu stören, das Ergebnis ist korrekt.
Das und topic.php?t=3087&page=fst_unread&highlight=append wagen einem zu glauben, dass der Parametertyp char erlaubt ist.

Vielleicht entsteht der Fehler beim UART-Empfang durch ganz andere Phänomene.
Das möchte ich unbedingt, auch in Eurem Interesse, ausschließen.

Gruß
Thomas

ich habe das Programm sehr vereinfacht, so dass die Variable charX ihre Bedeutung verloren hat.
Das Ursprungsprogramm empfängt und sendet Daten zum PC.
charX bekommt in diesem Programm den Wert von Seinp zugewiesen.
und empfangene Zeichen werden in einen String Puffer geschrieben.




Alle Test im Simulator waren erfolgreich und fehlerfrei.
Erst in der realen Welt traten sehr sporadisch Fehler auf.

Um den Fehler zu erzeugen, sende ich mit einem Terminalprogramm (HTerm) alle 100ms Daten zum uC. Bei ca. 10000 gesendeten Zeichen tritt der Fehler 10 Mal auf (siehe Bild). Also selten. Die Daten müssen offensichtlich zu einem bestimmten Zeitpunkt eintreffen, damit der Fehler auftritt.

Zuerst hatte ich nicht atomare read-modify Zugriffe in Verdacht, konnte allerdings keine finden.
Der Serport Treiber z.B. sperrt schön den globalen Interrupt während er auf _rxcount zugreift.

Dann habe ich irgendwann festgestellt, dass der Fehler nur bei Verwendung von append auftritt, wenn der erste Parameter vom Typ char ist.

Ich weiß, dass in der Doku char als typ nicht angegeben ist.
Trotzdem könnte die Funktion mit einem character für den erster Parameter fehlerfrei sein.

Messungen haben gezeigt, dass auch im Fehlerfall die Empfangs-Interrupt-Routine unmittelbar nach jedem Zeichen auf der RX Leitung angesprungen wird. Aber aus irgendeinem, mir nicht zu erklärbaren Grund, ist das Byte im UDR Register falsch. Es stellt sich so dar, als ob die Daten nicht vom UART Shift Register in den Daten Puffer UDR geschrieben wurden, der Interrupt aber auftritt. Ich kann mir das nicht erklären und träum davon schon Nachts.

Gruß

Hallo Rolf,

Der Fehler ist bisher nicht aufgetreten, wenn der erste Parameter von Append vom Typ String[1] ist.



Aber es gibt doch einen Unterschied:
String[1] bleibt in RAM und char wird vorher in die Register ACCELO und ACCEHI geschrieben.

In beiden Fällen bekommt Append die Adresse als Parameter.
Der Zugriff erfolgt dann später über das Z-Register.
StrInsert könnte ACCELO und ACCEHI überschreiben, da die Funktion davon ausgeht, dass der Parameter im RAM liegt. StrInsert schreibt tatsächlich in das ACCELO Register, aber erst nachdem es ausgelesen wurde.
Konnte nicht erkennen, dass ACCELO oder HI korrupt werden.

Ich habe allerdings noch nicht den kompletten ASM Code von StrIns durchgekaut, weil es mühselig ist.

Habe auch schon die Hardware gewechselt und mit ATMEGA16 ausprobiert. Keine Änderung.
Compilerversion ist bei mir übrigens 5.5.23

Gruß
Thomas