XMEGA Hardware-Bug (Kritisch)

[Carl D. (jcw2)]

Bernd schrieb:
> Was passiert, wenn das eine Sprungziel nicht auf Adresse 0 liegt?

Die Frage wollte ich auch schon stellen, aber nach .lss von 08:00 
scheint das keinen Unterschied zu machen.

[Stephan (Gast)]

Stephan B. schrieb:
> Nachtrag:
> 3) Wird ein drittes rjmp nach dem "übersehenem zweiten" wieder
> ausgeführt?

Kann ich beantwortenm mit: Endlosschleife

bei:

[...]
  /* corebug? */
  asm volatile (
  "loop%=:    \n\t"
  "  rjmp  jump%=  \n\t"
  "  nop    \n\t"
  "  break    \n\t"
  "  ret    \n\t"
  "jump%=:    \n\t"
  "  rjmp  loop%=  \n\t"
  "  rjmp  loop%=  \n\t"
    :
    :
    : "memory"
  );
[...]

MfG

[Stephan (Gast)]

Hmm, folgendes triggert den Bug: (KEINE Endlosschleife - letztes rjmp 
skipped)

  asm volatile (
  "rjmp .+2 \n\t"
  "nop    \n\t"
  "rjmp .-6 \n\t"
  );

Und folgendes funktioniert scheinbar korekt:

  asm volatile (
  "rjmp .+0 \n\t"
  "rjmp .-4 \n\t"
  );

MfG

[Venkman (Gast)]

Aus Interesse: push


Was hat sich denn ergeben?

[Mampf F. (mampf)]

Venkman schrieb:
> Aus Interesse: push
>
> Was hat sich denn ergeben?

Status immer noch unverändert, leider ... Müssen wohl noch etwas warten 
:)

[Dieter R. (drei)]

Mampf F. schrieb:
> Venkman schrieb:
>> Aus Interesse: push
>>
>> Was hat sich denn ergeben?
>
> Status immer noch unverändert, leider ... Müssen wohl noch etwas warten
> :)

Hat sich denn schon ein eifriger indischer Supportmitarbeiter gemeldet, 
oder nicht einmal der?

[Mampf F. (mampf)]

Dieter R. schrieb:
> Mampf F. schrieb:
>> Venkman schrieb:
>>> Aus Interesse: push
>>>
>>> Was hat sich denn ergeben?
>>
>> Status immer noch unverändert, leider ... Müssen wohl noch etwas warten
>> :)
>
> Hat sich denn schon ein eifriger indischer Supportmitarbeiter gemeldet,
> oder nicht einmal der?

Ich hab heute vor mittag im Case nochmal nachgefragt, ob es was neues 
gibt ... Bisher leider nicht :(

[YAG (Gast)]

Mampf F. schrieb:
> Ich hab heute vor mittag im Case nochmal nachgefragt, ob es was neues
> gibt ... Bisher leider nicht :(

Du hast mit einer privaten Adresse geschrieben oder?
Wenn ich mit meiner Arbeitsadresse schreibe, gibt es immer erheblich 
schneller eine Antwort. Wenn das in zwei Wochen noch liegt, sollte es 
vielleicht jemand mit Bosch/ST/Schneider/… E-Mail probieren.
Alternativ würde ich für halben Boost herhalten. Wir sind bei denen aber 
inzwischen kein sehr großer Kunde mehr.

Wobei vielleicht gerade das hilft -> ;).

Zuletzt sogar von ARM recht schnell Minimalsupport bekommen. Die haben 
sich dann sogar bei unserem Silicon Partner gemeldet, … der wäre 
eigentlich zuständig gewesen. War schon interessant zu verfolgen :D
Wobei ich überrascht war, dass unser Firmenname bei ihnen geläufig war. 
So groß sind wir auch wieder nicht. Keine 10k Mitarbeiter

[Mampf F. (mampf)]

I tried testing the scenarios at my end and I was unable to successfully build the code in Atmel Studio. I changed to below sequence and it worked properly.

rjmp PC+2

nop

rjmp PC-2

This worked with both single nop and multiple nop’s. Are you checking with Atmel Studio 7? The syntax didn’t work and failed with errors when I tried rjmp .+2 in Atmel Studio assembler.

facepalm ... seufz ... Vma darf er ja das "." entfernen, wenn Atmel 
Studio 7 eine andere Syntax benutzt, aber wieso hat er die Sprungadresse 
im zweiten rjmp geändert ..

Muss da nochmal darauf antworten :/

[Jörg W. (dl8dtl) (Moderator)]

Auch in Atmel Studio kann man den GNU Assembler benutzen, schließlich 
ist er Teil der von Atmicrochip mitgelieferten Toolchain.

Vermutlich solltest du ihm dafür allerdings am besten ein komplettes 
Studio-Projekt überhelfen.

[Mampf F. (mampf)]

Jörg W. schrieb:
> Auch in Atmel Studio kann man den GNU Assembler benutzen,
> schließlich
> ist er Teil der von Atmicrochip mitgelieferten Toolchain.
>
> Vermutlich solltest du ihm dafür allerdings am besten ein komplettes
> Studio-Projekt überhelfen.

Ich hab ihm den Tipp gegeben, dass er auch Labels verwenden kann.

l1:
  rjmp l2
  nop
l2:
  rjmp l1

Wie soll so jemand überhaupt qualifiziert sein, solch ein Problem zu 
verifizieren, wenn er am Allereinfachsten scheitert und offenbar nicht 
mal den Case verstanden hatte.

[Stefan F. (Gast)]

Erinnere dich daran, dass viele Leute hier im Forum (mich 
eingeschlossen) den Case auch nicht gleich verstanden haben. Vielleicht 
deswegen, weil er so unfassbar trivial ist.

Aber du lässt dich nicht so leicht unterkriegen. Bleibe dran!

[Dieter R. (drei)]

Mampf F. schrieb:

> Wie soll so jemand überhaupt qualifiziert sein, solch ein Problem zu
> verifizieren, wenn er am Allereinfachsten scheitert und offenbar nicht
> mal den Case verstanden hatte.

Ich hatte letztlich ähnliche Erfahrungen, habe ein komplettes Projekt 
geschickt, musste dem Mitarbeiter aber Step by Step erklären, wie man 
einige Optionen in Atmel Start bedient, denn dort entstand das Problem.

Anscheinend hat man den First Level Support nach Indien ausgelagert, mit 
allen diesbezüglichen Konsequenzen.

ABER: Man sollte auch nicht verlangen, dass der Mitarbeiter sich erst in 
die jeweilige Fragestellung einarbeiten und selbst ein Projekt aufsetzen 
muss. Das kostet überflüssig viel Zeit für ihn. Ein fertiges Projekt, 
das den Fehler zeigt, sollte man meiner Meinung nach immer schicken.

[Jörg W. (dl8dtl) (Moderator)]

Dieter R. schrieb:

> Anscheinend hat man den First Level Support nach Indien ausgelagert,

Schon lange, und auch einen Teil der Softwareentwicklung.

Wesentliches Problem dort ist nicht, dass die Leute zu blöd wären, 
sondern eine insgesamt hohe Fluktuation. Außerdem, im Ernst: 
Firstlevel-Support wurde wohl schon immer nicht gerade von ausgemachten 
Ingenieuren bedient, denn 99 % der Fragen, die da ankommen, sind 
Standardfragen, die sich nach Schema F beantworten lassen. Der Supporter 
muss eigentlich nur in die Lage versetzt werden zu erkennen, wenn 
irgendein Problem ein tatsächlicher Bug ist. Den kann er dann 
weiterreichen, womit er seinen Anteil als erledigt abhaken kann (die 
Leute werden nach Durchsatz bewertet).

> Ein fertiges Projekt,
> das den Fehler zeigt, sollte man meiner Meinung nach immer schicken.

Ja, ein fertiges "how to reproduce" hilft immer. Am besten noch, wenn 
man es für ein offizielles Atmel-Demo-Board aufbereitet und er anhand 
des (Nicht-)Blinkens der dortigen LED erkennen kann, dass das wirklich 
nicht so funktioniert wie es sollte.

[Frank M. (ukw) (Moderator)]

Bitte wieder zum Thema zurückkommen. Es wäre schade, wenn ein solch 
spannendes Thema (es geht um einen XMEGA-Bug) wegen Animositäten 
zerpflückt und damit unlesbar wird.

[Dieter R. (drei)]

Frank M. schrieb:
> Bitte wieder zum Thema zurückkommen. Es wäre schade, wenn ein solch
> spannendes Thema (es geht um einen XMEGA-Bug) wegen Animositäten
> zerpflückt und damit unlesbar wird.

Gute Idee. Noch besser wäre es, wenn jemand mit entsprechender Hardware 
diesen Ratschlag aufnehmen könnte:

Am besten noch, wenn man es für ein offizielles Atmel-Demo-Board 
aufbereitet und er anhand des (Nicht-)Blinkens der dortigen LED erkennen 
kann, dass das wirklich nicht so funktioniert wie es sollte.

Ich lese diesen Thread mit Interesse, muss aber beim Demo-Board passen.

[Jörg W. (dl8dtl) (Moderator)]

Ich habe leider auch kein Demoboard mit dem Xmega E (nicht einmal einen 
solchen überhaupt), obwohl ich einige Demoboards rumfliegen habe.

[Holm T. (Gast)]

Jörg W. schrieb:
> Ich habe leider auch kein Demoboard mit dem Xmega E (nicht einmal einen
> solchen überhaupt), obwohl ich einige Demoboards rumfliegen habe.

Kuhl, da steht sogar ein "lesenswert" an Deinem Beitrag.. für was denn?
Ich habe nur XMegaA3 und A3BU ..ist das auch lesenswert?

Gruß,

Holm

[rbx (Gast)]

Holm T. schrieb:
> .ist das auch lesenswert?

Auf jeden Fall und zusammen mit/seit dem Emailzitat oben ("kein Problem 
mit -2 Sprung") 8-fache Bonuspoints.

[H.Joachim S. (crazyhorse)]

Holm T. schrieb:
> Kuhl, da steht sogar ein "lesenswert" an Deinem Beitrag.. für was denn?

Was hast du eigentlich für ein Problem?
Hat man dir ein (wahrscheinlich sinnfreies) posting genommen und kommst 
damit nicht klar?

[Peter D. (peda)]

Schade, wie ein eigentlich interessanter Thread durch einen einzelnen 
mit Müll geflutet wird. Und der kapiert es nicht mal.

[Frank M. (ukw) (Moderator)]

Holm T. schrieb im Beitrag #5910092:
> Dochdoch, der kapiert es schon, läßt aber nicht Alles diskussionslos mit
> sich machen.

Mach das bitte in dem dafür bestimmten Unterforum. Andere Threads wegen 
Deiner Misslaune zu kapern und dann mit Müll zu fluten, nur um zu 
zeigen, dass Du heute wieder einen Scheiß-Tag hast, ist eine 
Unverschämtheit seinesgleichen.

Merkst Du eigentlich nicht, dass Du damit schon Dutzende von Threads 
kaputtgemacht hast? Hast Du noch gar nicht mitbekommen, dass unter den 
Usern für dieses Phänomen sogar schon ein neuer Fachbegriff "zugeholmt" 
kreiert wurde?

Solltest Du wieder absichtlich Deine "persönliche Meinung" in Form von 
Respektlosigkeit mit "Wissen" in einem Beitrag mischen, werde ich mir 
zukünftig nicht mehr die Mühe machen, Teile rauszulöschen, sondern 
Deinen Beitrag halt komplett löschen.

Wir sind uns da unter uns Moderatoren einig: Bei ausgesprochener 
Respektlosigkeit fliegt ein Beitrag - egal von wem geschrieben. Wenn Dir 
das nicht passt, suche Dir bitte eine andere Plattform.

[Frank M. (ukw) (Moderator)]

Der Thread wird temporär gesperrt, bis Mampf neue Erkenntnisse von 
Microchip hat.

@Mampf: Melde Dich bitte bei einem der Moderatoren, sobald Du etwas 
Neues weisst. Dann wird dieser Thread wieder freigeschaltet.

[Mampf F. (mampf)]

Neue Infos:

> Thank you for sharing the sequence for testing. I tested with this as
> well, and the code seems to enter into the endless loop as expected.
> Can you please share a screen capture video of how the code behaves at
> your end? Is it coming out of the loop in Xmega E device? I tested in
> Xmega E5 Xplained board and used Atmel ICE for debugging.
>
> Also, please share the details of Atmel Studio version and tool you’re
> using for debugging so that I can test with the same here.


Hmmm, so wie es aussieht, konnten sie die Probleme bislang nicht 
reproduzieren - oder die XMEGAs verhalten sich anders, wenn sie mit ICE 
debuggt werden.

Ich hab leider keinen XMEGA, weshalb ich nicht selbst testen kann und 
extra kaufen möchte ich mir keinen, da ich die sonst nicht verwende.

Was machen wir nun? :-)

[Marcus H. (Firma: www.harerod.de) (lungfish)]

Mampf F. schrieb:
...
> Was machen wir nun? :-)

Ganz trocken und nüchtern: wenn es jemanden genug interessiert und er 
das Problem nicht darstellen kann, dann könnte man einen Megaprofi* mit 
einem Forschungsprojekt inkl. Budget ausstatten.

Ich habe in den letzten zwanzig Jahren einige Bugs in Chips aufgetan, 
die dann auch ihren Weg in die nächsten Datenblätter gefunden haben. 
Vorgehensweise ist immer, dass man mit einem sauber dokumentierten Fund 
zum Support geht. Bei vielen Herstellern habe ich nach kurzer Zeit 
üblicherweise einen Kontakt in die Entwicklung (TI, Micrel, ADI). Bei 
anderen Herstellern (Atmel) wurde zumindest oft genug der Fehler in die 
nächsten Errata eingetragen. Gerade bei Atmel bin ich seit den Desastern 
mit AT91RM9200 und AVR32AP immer noch skeptisch. Wobei ich das Gefühl 
habe, dass Microchip den Laden aufräumt. STM32 sind so weit verbreitet, 
dass bei den Hauptvertretern jeweils andere in kurzer Zeit die Bugs 
finden. Ein Grund warum man Kunden regelmäßig zum Einsatz von nicht 
brandneuen Bausteinen rät und von der Verwendung von Nischenprodukten 
abrät.


*Megaprofi: Jemand der anders als der TO an das Thema rangeht.

[Mampf F. (mampf)]

Marcus H. schrieb:
> Ich habe in den letzten zwanzig Jahren einige Bugs in Chips aufgetan,
> die dann auch ihren Weg in die nächsten Datenblätter gefunden haben.
> Vorgehensweise ist immer, dass man mit einem sauber dokumentierten Fund
> zum Support geht. Bei vielen Herstellern habe ich nach kurzer Zeit
> üblicherweise einen Kontakt in die Entwicklung (TI, Micrel, ADI).

Hier scheitert es leider schon am (vmtl) 1st-Level support und man kommt 
gar nicht weiter^^

[Christopher J. (christopher_j23)]

Mampf F. schrieb:
> Hmmm, so wie es aussieht, konnten sie die Probleme bislang nicht
> reproduzieren - oder die XMEGAs verhalten sich anders, wenn sie mit ICE
> debuggt werden.

Wenn es ein Problem mit der Pipeline ist, würde ich sogar relativ sicher 
sagen, dass der XMEGA sich anders verhält wenn man da im single 
instruction mode mit dem Debugger durchgeht. Ein typischer Heisenbug 
eben ;)

Unter Umständen könnte man den Bug aber reproduzieren, indem man einfach 
einen Breakpoint hinter der Endlosschleife setzt. Der sollte dann 
entsprechend nie getriggert werden und falls doch, hat man den Bug 
eindeutig reproduziert.

[Stefan F. (Gast)]

Wenn das Problem für mich relevant wäre, hätte ich längst ein aktuelle 
Evaluation Board vom Hersteller gekauft, es darauf reproduziert und dann 
das ganze Projekt (eventuell samt Hardware) zum Hersteller geschickt. 
Damit es dort auch reproduzierbar ist.

Superprofi, du musst den Hersteller davon überzeugen, dass es sich um 
ein Problem im Chip handelt, nicht um ein Problem in der Anwendung. Und 
mache das so, dass sie dies mit möglichst wenig Aufwand erkennen können. 
Denn großartig Arbeitszeit für Nachforschungen werden sie erst rein 
stecken, wenn sie von der Notwendigkeit überzeugt sind.

Denke immer dran, dass jeder Mensch der Welt mit so einer Behauptung 
ankommen könnte. Sicher sind mehr als 95% davon Irrtümer.

[Christopher J. (christopher_j23)]

Stephan B. hat doch in 
Beitrag "Re: XMEGA Hardware-Bug (Kritisch)" schon eine 
schöne Demo für den Bug geschrieben. Man muss eigentlich nur den Pin für 
die LED so abändern, dass der Atmelsupport das auf seinem Xplained Board 
laufen lassen kann (mit dem Hinweis die Finger vom Debugger zu lassen).

[Bastian W. (jackfrost)]

Ich konnte den Bug ja auch auf meinem Board mit den XMega nachstellen. 
Wenn nach dem nop noch was kam dann hat es funktioniert wenn nur die 
nops waren nicht.

Gruß JackFrost

[Johann L. (gjlayde)]

Atmochip schrieb:
>> Is it coming out of the loop in Xmega E device? I tested in
>> Xmega E5 Xplained board and used Atmel ICE for debugging.

Gaaanz wichtig ist natürlich, dass sie den Finger von Debugging lassen, 
also kein Einzelschritt Modus, keine Breakpoints, etc. verwenden.

Und natürlich den gleichen Chip (ATxmega32E5), gleichen Produktion Code 
(1542) verwendet, am besten natürlich auch gleiche VCC (3.3V) und FCPU 
(2MHz), gleiche Fuses (Default).

>> Also, please share the details of Atmel Studio version and tool you’re
>> using for debugging so that I can test with the same here.

Hier am besten den Code direkt hinschicken (.elf und .lst oder 
komplettes  Minimal-Projekt) und erklären, was passiert.  Günstig ist 
dann, möglichst wenig Anforderung an die Beschaltung zu haben, z.B. 
einfach nur ein Pin wackeln.

Und nochmal betonen dass es NICHT um Debugging geht (und schon garnicht 
um Simulation).

> Hmmm, so wie es aussieht, konnten sie die Probleme bislang nicht
> reproduzieren - oder die XMEGAs verhalten sich anders, wenn sie mit ICE
> debuggt werden.

Debuggen ist natürlich eine ganz schlechte Herangehensweise... keine 
Idee wie man bei potentiellem Silicon-Bug nen Debugger in Erwägung 
ziehen kann, als wäre es ein Software-Problem.

> Ich hab leider keinen XMEGA, weshalb ich nicht selbst testen kann und
> extra kaufen möchte ich mir keinen, da ich die sonst nicht verwende.

Am besten macht jemand nen Report, der das Artefakt nachvollziehen kann 
und dann möglichst punktgenaue Infos liefert.

[Jan (Gast)]

Mir ist schon völlig klar, warum Superprofi :D den Bug einfach hierhin 
gerotzt hat, statt ein grosses Projekt daraus zu machen und dann 
freudestrahlend damit zu Microchip zu rennen. Warum sollte er??? Seine 
Zeit ist bestimmt genauso kostbar wie jedem anderes Zeit hier auch. Für 
sich geheim halten wollte er es aber auch nicht. Ich denke, dass das ein 
guter Kompromiss war.

Man sieht ja, was passiert, hätte er den Weg zu Microchip eingeschlagen. 
Der Weg ist steil, die Thronwachen dämlich hartnäckig, dafür mit fetten 
Schilden ausgestattet. Warum sollte er sich da durch kämpfen? Für welche 
Belohnung? Für die Ehre? Den Dank des Königs? Leute, wacht auf. 
Ernsthaft. Die Welt ist kein scheiss Märchen.

[Jan (Gast)]

Nachtrag: Der Grund, warum ich jetzt den alten Thread hochgespült habe 
ist, dass wir jetzt alle schriftlich haben, dass da nichts passieren 
wird, was der ein oder andere ja vllt sich schon heimlich gedacht hat. 
Schreibt euch den Bug einfach in eure eigene Errata und gut ist.

[Stefan F. (Gast)]

Sollen wir zusammen weinen?
Dieses Nachtreten hilft doch niemanden.

[Jörg W. (dl8dtl) (Moderator)]

Stefan ⛄ F. schrieb:
> Dieses Nachtreten hilft doch niemanden.

Ich habe es eigentlich nur stehen lassen in der Hoffnung, dass sich 
mampf vielleicht nochmal meldet, ob sein "Fall" nun noch irgendwie 
weiter bearbeitet worden war.

[Moby (Gast)]

Jan schrieb:
> Der Grund, warum ich jetzt den alten Thread hochgespült habe
> ist, dass wir jetzt alle schriftlich haben, dass da nichts passieren
> wird,

Ja ganz interessant. Interessanter aber, den Bug auf diese Weise 
erstmalig zu erfahren, danke Jan :) Habs auf einem 32E5er Rev.B jetzt 
auch mal nachvollzogen. RJMP vorwärts direkt auf RJMP und Code 
dazwischen trifft das Ziel nicht. Nun ja, klingt auch ziemlich sinnlos, 
ist jedenfalls kein guter Asm-Stil. Davon abgesehen sollte man (auf 
Xmega, mit genug Flash) sowieso grundsätzlich absolutes JMP verwenden. 
Dann gibts generell keine Sprungprobleme mehr.

[Stephan B. (matrixstorm)]

Moby schrieb:
> Davon abgesehen sollte man (auf
> Xmega, mit genug Flash) sowieso grundsätzlich absolutes JMP verwenden.
> Dann gibts generell keine Sprungprobleme mehr.

Ändert nichts am BUG - ist maximal ein Workaround den Microchip 
vorschlagen (und Compiler entsprechend patchen) müsste.

MfG

[Peter D. (peda)]

Moby schrieb:
> Davon abgesehen sollte man (auf
> Xmega, mit genug Flash) sowieso grundsätzlich absolutes JMP verwenden.

Wer schreibt denn sowas vor?
Natürlich sollte ein Compiler immer den kürzest möglichen Befehl nehmen, 
der die Distanz schafft.

[Moby (Gast)]

Der TE verwendet so wie ich Assembler pur und keinen Compiler. Daran 
gibts leider nichts zu patchen wenn es denn ein Hardware-Bug ist.

Interessanterweise führt ein

m1: rjmp m2
jmp xx
m2: rjmp m1

nicht zum Fehler, d.h. mit JMP oder auch CALL statt NOP oder anderem 
Befehl unmittelbar dem ersten RJMP folgend funktioniert die Schleife.

[Mampf F. (mampf)]

Ah, Thread wieder aktiv :)

Zum Grund, wieso ich das nicht weiter verfolgt hatte, nachdem die erste 
Rückmeldung von Microchip negativ war:

Ich hätte mich schlicht damit näher befassen müssen, d.h. den Bug auf 
echter Hardware wirklich nachvollziehen müssen ...XMEGAs halte ich eh 
nicht so für besonders relevant und ich hab auch keine Hardware damit, 
daher verlief das dann im Sand.

Falls jemand einen neuen Versuch bei Microchip machen möchte, könnte ich 
sicherlich die Case-Nummer zur Verfügung stellen.