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 B. schrieb: > Nachtrag: > 3) Wird ein drittes rjmp nach dem "übersehenem zweiten" wieder > ausgeführt? Kann ich beantwortenm mit: Endlosschleife bei:
1 | [...] |
2 | /* corebug? */ |
3 | asm volatile ( |
4 | "loop%=: \n\t" |
5 | " rjmp jump%= \n\t" |
6 | " nop \n\t" |
7 | " break \n\t" |
8 | " ret \n\t" |
9 | "jump%=: \n\t" |
10 | " rjmp loop%= \n\t" |
11 | " rjmp loop%= \n\t" |
12 | : |
13 | : |
14 | : "memory" |
15 | ); |
16 | [...] |
MfG
Hmm, folgendes triggert den Bug: (KEINE Endlosschleife - letztes rjmp skipped)
1 | asm volatile ( |
2 | "rjmp .+2 \n\t" |
3 | "nop \n\t" |
4 | "rjmp .-6 \n\t" |
5 | ); |
Und folgendes funktioniert scheinbar korekt:
1 | asm volatile ( |
2 | "rjmp .+0 \n\t" |
3 | "rjmp .-4 \n\t" |
4 | ); |
MfG
Beitrag #5872560 wurde vom Autor gelöscht.
Venkman schrieb: > Aus Interesse: push > > Was hat sich denn ergeben? Status immer noch unverändert, leider ... Müssen wohl noch etwas warten :)
Beitrag #5893835 wurde von einem Moderator gelöscht.
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?
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 :(
:
Wiederhergestellt durch Moderator
Beitrag #5894148 wurde von einem Moderator gelöscht.
Beitrag #5894154 wurde von einem Moderator gelöscht.
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
1 | 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. |
2 | |
3 | rjmp PC+2 |
4 | |
5 | nop |
6 | |
7 | rjmp PC-2 |
8 | |
9 | 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 :/
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.
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.
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!
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.
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.
:
Bearbeitet durch Moderator
Beitrag #5909110 wurde von einem Moderator gelöscht.
Beitrag #5909114 wurde von einem Moderator gelöscht.
Beitrag #5909129 wurde von einem Moderator gelöscht.
Beitrag #5909133 wurde von einem Moderator gelöscht.
Beitrag #5909135 wurde vom Autor gelöscht.
Beitrag #5909144 wurde von einem Moderator gelöscht.
Beitrag #5909146 wurde von einem Moderator gelöscht.
Beitrag #5909148 wurde von einem Moderator gelöscht.
Beitrag #5909150 wurde von einem Moderator gelöscht.
Beitrag #5909152 wurde von einem Moderator gelöscht.
Beitrag #5909164 wurde von einem Moderator gelöscht.
Beitrag #5909177 wurde von einem Moderator gelöscht.
Beitrag #5909190 wurde von einem Moderator gelöscht.
Beitrag #5909193 wurde von einem Moderator gelöscht.
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.
Beitrag #5909203 wurde von einem Moderator gelöscht.
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.
Ich habe leider auch kein Demoboard mit dem Xmega E (nicht einmal einen solchen überhaupt), obwohl ich einige Demoboards rumfliegen habe.
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
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.
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?
Beitrag #5909969 wurde von einem Moderator gelöscht.
Schade, wie ein eigentlich interessanter Thread durch einen einzelnen mit Müll geflutet wird. Und der kapiert es nicht mal.
Beitrag #5909989 wurde von einem Moderator gelöscht.
Beitrag #5910092 wurde von einem Moderator gelöscht.
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.
:
Bearbeitet durch Moderator
Beitrag #5910210 wurde von einem Moderator gelöscht.
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.
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? :-)
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.
:
Bearbeitet durch User
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^^
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.
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.
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).
:
Bearbeitet durch User
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
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.
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.
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.
Sollen wir zusammen weinen? Dieses Nachtreten hilft doch niemanden.
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.
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.
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
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.
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
1 | m1: rjmp m2 |
2 | jmp xx |
3 | 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.
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.