XMega noch unbekannter HW-Bug

[Elektrolurch (Gast)]

Hallo,

ich wollte einen seltsamen und noch unbekannten HW-Bug hier 
melden/vorstellen.

- Dieser Fehler tritt bei mir bei Timer TCE0 im PWM-Betrieb (ca. 71kHZ)
  auf (andere Timer nicht getestet)

=> Beim schreiben auf das .CCBBUF-Register mit einem Wert wird
   *sporadisch/sehr selten* der Wert des .PERBUF(low)-Registers
   verfälscht!!!
   Daraus folgend, wird eine(!) PWM-Periode verfälscht!

=> Das ist KEIN Programmier- oder Compilerfehler!
   (Habe das im Disassembly-Fenster nachgeschaut)

==> Workaround:
Wenn nach: TCE0.CCBBUF= uint16_t;
Das Register TCE0.PERBUFL gelesen wird (z.B. if(TCE0.PERBUFL != 
wert)...
tritt der Fehler nicht mehr auf!

- Prozessor ATXMega64A3U Rev. G
- Taktfrequenz: 32MHz (ext.), Ub= 3,3V
- 1 DMA-Kanal mit 430kByte/s und mehrere INT-Routinen aktiv

[Ingo L. (corrtexx)]

Elektrolurch schrieb:
> Wenn nach: TCE0.CCBBUF= uint16_t;
> Das Register TCE0.PERBUFL gelesen wird (z.B. if(TCE0.PERBUFL !=
> wert)...
> tritt der Fehler nicht mehr auf!
Hast du mal einen atomaren Zugriff auf das CCBBUF Register probiert?!

[Falk B. (falk)]

@Elektrolurch (Gast)

>=> Das ist KEIN Programmier- oder Compilerfehler!
>   (Habe das im Disassembly-Fenster nachgeschaut)

Das sagen sie alle ;-)

Zeig mal den Quelltext und das Assemblerlisting.

>==> Workaround:
>Wenn nach: TCE0.CCBBUF= uint16_t;
>Das Register TCE0.PERBUFL gelesen wird (z.B. if(TCE0.PERBUFL !=
>wert)...
>tritt der Fehler nicht mehr auf!

>- Prozessor ATXMega64A3U Rev. G
>- Taktfrequenz: 32MHz (ext.), Ub= 3,3V
>- 1 DMA-Kanal mit 430kByte/s und mehrere INT-Routinen aktiv

Möglicherweise kommen sich mehrere Interrupts in die Quere. Oder 
gemeinsame Pufferregister werden doppelt benutzt. Da ist wahrscheinlich 
irgendwas nicht ganz atomar.

https://www.mikrocontroller.net/articles/Interrupt#Atomarer_Datenzugriff

[Ingo L. (corrtexx)]

Elektrolurch schrieb:
> => Das ist KEIN Programmier- oder Compilerfehler!
>    (Habe das im Disassembly-Fenster nachgeschaut)
Was das Disassembly dir nicht verrät ist, das ein Interrupt wärend des 
Schreibvorganges dazwischen funken kann. Dann nämlich gibts korrupte 
Daten wie du schon gemerkt hast. Der Compiler kann nichts dafür, der 
arme AVR auch nicht. Schuld ist wie so oft der Programmierer der den 
atomaren Zugriff auf Register > 8Bit auf einem 8Bit Controller vergisst.

[Peter D. (peda)]

Elektrolurch schrieb:
> => Beim schreiben auf das .CCBBUF-Register mit einem Wert wird
>    *sporadisch/sehr selten* der Wert des .PERBUF(low)-Registers
>    verfälscht!!!

Diese Problem ist auch von den classic AVRs bekannt. Die AVRs sind 
8Bitter, d.h. ein Schreibzugriff auf 16Bit ist nicht atomar. Er muß 
daher atomar gekapselt werden (atomic.h).
Grund ist, daß das temporäre high-Register von allen Timerregistern 
gemeinsam verwendet wird.
"The same temporary register is shared between all 16-bit registers 
within each 16-bit timer."

P.S.:
Eigentlich sollte dann aber das high-Byte verfälscht sein.

[Elektrolurch (Gast)]

Hallo,

habe vergessen zu erwähnen, dass der CCBBUF-Zugriff in einem 
HI-Level-Interrupt erfolgt - daher kann eigentlich kein anderer INT 
dazwischen funken.

>> Schuld ist wie so oft der Programmierer der den
atomaren Zugriff auf Register > 8Bit auf einem 8Bit Controller vergisst.

Ja das Problem kannte ich zu gut, ABER:
- der Zugriff erfolgt NICHT auf das Zählerregister, sondern auf ein 
BUFFER-Register!
- außerdem besitzt der Xmega extra eine Hardware um die 
16Bit-Peripherie
quasi-atomar ansprechen zu können!

* So, habe jetzt alle anderen INTs abgeschaltet - Fehler.
* Habe DMAs gecheckt: Kein schreiben auf PERBUF
* Habe Stack gecheckt, kein Überlauf.
* Das Programm läuft etwas über 120ms bis die Veränderung erkannt 
wird/passiert.

Ich finde die Stelle, an der das CCBUF verändert wird einfach nicht!

PS:
Das Programm ist sehr komplex und kommuniziert mit einer anderen 
Platine.
Deshalb ist es praktisch unmöglich, den nötigen Quelltext anzugeben.

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

Elektrolurch schrieb:

> Das Programm ist sehr komplex und kommuniziert mit einer anderen
> Platine.
> Deshalb ist es praktisch unmöglich, den nötigen Quelltext anzugeben.

Dann könnte man z.B. alle Teile, die vermutlich nichts mit dem Effekt zu 
tun haben, entfernen und so ein Minimalprogramm erzeugen, das den Fehler 
zeigt. Dieses ließe sich dann problemlos an Dritte weitergeben -- wenn 
es denn den beschriebenen Fehler aufweist...

Ansonsten können Dir vermutlich nur telepathisch begabte Menschen 
weiterhelfen...

Grüßle,
Volker.

[WaMin (Gast)]

Elektrolurch schrieb:
> Das Programm ist sehr komplex

Daher ist es nötig, dass du ein Minimalprogramm erzeugst, das das 
Verhalten reproduzierst.
Anders kann dir weder geholfen werden, noch der mögliche HW-Bug 
eingegrenzt werden.

[Pete K. (pete77)]

Schicke Deine Beobachtung doch an Microchip(AVR). Die können das 
bestimmt beurteilen und sind sicher dankbar für solche Hinweise.

[Soul E. (Gast)]

Mit etwas Glück schicken sie Dir das zu Deiner Beobachtung passende 
Errata-Sheet. Was Du natürlich wegen NDA nicht weitergeben darfst ;-)

Das ist das Schöne an den Japanern. Da bekommt man die Errata wenigstens 
regelmässig unaufgefordert zugeschickt. Weitergeben darf man sie aber 
auch nicht.