Announcement: there is an English version of this forum on Hallo, da ich nur in Assembler programmiere, muss ich höllisch aufpassen, nicht aus Versehen in folgenden Hardware-Bug zu laufen: 2: rjmp 1f nop 1: rjmp 2b Kompiliert zu: rjmp .+2 nop rjmp .-6 Eigentlich sollte es eine Endlosschleife sein, aber er überspringt den letzten rjmp. Wer jetzt sagt, dass man so ein Konstrukt eh nicht einsetzt, hat natürlich recht. Allerdings kommt dieses Konstrukt in abgewandelter Form öfters vor, als man denkt: mainloop: 1: ifnot Gtcc5_overflows,2f dec Gtcc5_overflows rcall taskmanager_execute_tasks_r31 rjmp 1b 2: nop ;Komischer HW Bug Work Around... rjmp mainloop Vielleicht mache ich ja auch etwas falsch, aber ich fürchte nicht... :( (Getestet auf XMEGA E)
:
Gesperrt durch Moderator
Superprofi schrieb: > 2: > rjmp 1f > nop > 1: > rjmp 2b Was soll den dass werden? Ein Wettbewerb für unlesbaren Code? Wo willst du denn mit "1f" bzw. "2b" hin springen? Erstmal benutzt man anständige Namen für Sprungmarken. Und dann benutzt man die, dann funktioniert es auch wie erwartet:
anfang: rjmp weiter nop weiter: rjmp anfang |
:
Bearbeitet durch User
Superprofi schrieb: > 2: > rjmp 1f > nop > 1: > rjmp 2b > > > Kompiliert zu: > > rjmp .+2 > nop > rjmp .-6 > > > Eigentlich sollte es eine Endlosschleife sein, aber er überspringt den > letzten rjmp. Deine Aussage verstehe ich nicht. rjmp .+0 springt zum nächsten Befehl. Das verwende ich als NOP mit zwei Taktzyklen. Dann sollte das rjmp .+2 von oben genau auf das rjmp .-6 springen,würde also m.E. genau das machen, was es soll. Grüßle Volker
1f könnte Zieladresse 1 "f"orwärts und 2b Zieladresse 2 "b"ückwärts heissen. Gar nicht mal so dumm...
Stefanus F. schrieb: > Erstmal benutzt man anständige Namen für Sprungmarken. Und dann benutzt > man die, dann funktioniert es auch wie erwartet: > >
> anfang: > rjmp weiter > nop > weiter: > rjmp anfang > |
Gut, dass ich nicht "man" bin, denn ich erachte die relativen Labels des GNU-Assemblers für sehr praktisch. Ich möchte mir nicht vorstellen, wie unübersichtlich ein Assemblerprogramm wird, wenn ich 30 "weiter" und "anfang" Labels verwenden müsste. Bei 1f weiß ich sofort, dass an das nächste im Programmablauf folgende Label 1 gesprungen wird, welches sich aus Lesbarkeitsgründen dann natürlich auch in der folgenden Hand voll Codezeilen befinden sollte. Das erachte ich für lesbarer als von weiter29 nach anfang30 zu springen. Grüßle Volker
Hi >Das erachte ich für lesbarer als von >weiter29 nach anfang30 zu springen. Da hast schon mal 10..20k große Assemblerprogramme geschrieben? MfG Spess
Volker B. schrieb: > Dann sollte das rjmp .+2 von oben genau auf das rjmp .-6 springen,würde > also m.E. genau das machen, was es soll. Richtig. Und DANN? Erst dann kommt ja das Problem! Er sollte danach zurück springen. Tut er aber nicht! Der rjmp .-6 wird einfach gnadenlos ignoriert.
Superprofi schrieb: > Volker B. schrieb: >> Dann sollte das rjmp .+2 von oben genau auf das rjmp .-6 springen,würde >> also m.E. genau das machen, was es soll. > > Richtig. Und DANN? Erst dann kommt ja das Problem! Er sollte danach > zurück springen. Tut er aber nicht! Der rjmp .-6 wird einfach gnadenlos > ignoriert. Funktioniert es denn mit ordentlichen Labels? Dann ist das Problem ja abgefrühstückt.
spess53 schrieb: > Hi > >>Das erachte ich für lesbarer als von >>weiter29 nach anfang30 zu springen. > > Da hast schon mal 10..20k große Assemblerprogramme geschrieben? OMG, natürlich verwende ich auch "sprechende Labels" aber eben nicht für jeden Sprung. Grüßle Volker
Ok ich wusste bisher gar nicht, dass es solche relativen Labels gibt. Jetzt weiß ich dass es sie gibt und ich sie nicht benutzen sollte. :)
Peter Petersson schrieb: > Ok ich wusste bisher gar nicht, dass es solche relativen Labels gibt. > Jetzt weiß ich dass es sie gibt und ich sie nicht benutzen sollte. :) Vor allem: wozu sollte man sie benutzen? Was interessiert mich die Sprungweite, das kann doch der Assembler ausrechnen. Bis zum Beweis des Gegenteils vermute ich auch, dass da das Problem liegt.
Und was hat das ganze übrigens mit "Hardware-Bug" zu tun wenn in Wirklichkeit nur Dein komischer Assembler sich verrechnet? Welcher Assembler überhaupt?
:
Bearbeitet durch User
Stefanus F. schrieb: > Erstmal benutzt man anständige Namen für Sprungmarken. Nö. 1b,2f sind unter GAS völlig übliche Schreibweisen, um lokale Labels in Macros zu generieren. https://docs.oracle.com/cd/E19120-01/open.solaris/817-5477/esqat/index.html
Selbst ich - und das will was heißen - habe bislang immer gut daran getan den spontanen Impuls zu unterdrücken irgendeinen obskuren Bug im Compiler/Linker/Assembler/Hardware in die Welt hinaus zu posaunen denn nach weiteren 10 Minuten habe ich stets (ausnahmslos!) den Fehler bei mir selbst gefunden und somit schon weit mehr als einmal durch bloße Willenskraft(!) vermieden mich der Lächerlichkeit preiszugeben.
:
Bearbeitet durch User
Beitrag #5861232 wurde von einem Moderator gelöscht.
Beitrag #5861233 wurde von einem Moderator gelöscht.
Beitrag #5861283 wurde von einem Moderator gelöscht.
Bernd K. schrieb: > Selbst ich - und das will was heißen - habe bislang immer gut daran > getan den spontanen Impuls zu unterdrücken irgendeinen obskuren Bug im > Compiler/Linker/Assembler/Hardware in die Welt hinaus zu posaunen denn > nach weiteren 10 Minuten habe ich stets (ausnahmslos!) den Fehler bei > mir selbst gefunden und somit schon weit mehr als einmal durch bloße > Willenskraft(!) vermieden mich der Lächerlichkeit preiszugeben. Auja! Aber nach 30min Recherche landet man dann vllt doch mal einen Treffer: https://sourceware.org/bugzilla/show_bug.cgi?id=22493 (Hat einer der Studenten gefunden und ich habs dann noch anhand des RefMan verifiziert)
Mw E. schrieb: > Aber nach 30min Recherche landet man dann vllt doch mal einen Treffer: Was hat der ARM Cortex-7 mit dem AVR XMega E zu tun? Habe ich da etwas übersehen?
Superprofi schrieb: > Kompiliert zu: Welche Umgebung / welchen Assembler nutzt Du denn? Zeig doch bitte auch mal die resultierenden Meldungen - das .lls-File wäre auch interessant.
Superprofi schrieb: > Kompiliert zu: > > rjmp .+2 > nop > rjmp .-6 1) Das ist ohne Hexcode nicht sonderlich transparent! Wenn man den nicht im Hinterkopf hat kann man nur raten, bzw. muss woanders nachschauen. 2) Einen Bug unterstellen, ohne Debugger zur Hilfe/als Referenz zu nehmen - erscheint voreilig? 3) Der Transparenz und Einfachheit zuliebe kann man bei solchen Diskussionen/Fragen Pseudocode einsetzen, bzw. so vorgehen, wie Stefanus oben schreibt.
Superprofi schrieb im Beitrag #5861232: > LOL soviel Bullshit ist selbst für dieses Forum ein Novum. Hat das > überhaupt mal jemand ausprobiert? Wahrscheinlich nicht. Wahrscheinlich > nicht mal das Problem verstanden. Ohne Worte. Hast du es verstanden? Vermutlich nicht mal im Ansatz. Die Vermutung im Forum geht dahin, dass a) es kein Hardware-Bug ist (sonst würde vieles nicht laufen, nicht nur deine Unsinns-Endlosschleife) b) deine ungewöhnliche Programmiertechnik einen Fehler im Assembler (weniger wahrscheinlich) oder im Linker (mehr wahrscheinlich) generiert. Du bist mehrfach und mit verschiedenen Worten gebeten worden, das durch entsprechenden Testcode zu verifizieren. Darauf warten wir aber alle bisher vergeblich. Stattdessen tust du dich mit brüllendem Bashing hervor. Das unterstützt nicht gerade den Eindruck von Super-Professionalität.
Dieter R. schrieb: > Peter Petersson schrieb: >> Ok ich wusste bisher gar nicht, dass es solche relativen Labels gibt. >> Jetzt weiß ich dass es sie gibt und ich sie nicht benutzen sollte. :) > > Vor allem: wozu sollte man sie benutzen? Was interessiert mich die > Sprungweite, das kann doch der Assembler ausrechnen. Bis zum Beweis des > Gegenteils vermute ich auch, dass da das Problem liegt. Die Nummern in den relativen Labels haben nichts mit der Sprungweite im Code zu tun. q.e.d.
Sven P. schrieb: > Die Nummern in den relativen Labels haben nichts mit der Sprungweite im > Code zu tun. Ja, danke. Ich kannte die Programmierweise nicht, habe ich inzwischen nachgelesen und begriffen. Trotzdem vermute ich, dass da das Problem liegt, siehe mein Beitrag davor. Damit sollte sich aber jetzt mal der Threadersteller auseinandersetzen statt uns hier alle zu beschimpfen.
Sven P. schrieb: >>> Ok ich wusste bisher gar nicht, dass es solche relativen Labels gibt. >>> Jetzt weiß ich dass es sie gibt und ich sie nicht benutzen sollte. :) Die gibt es auch nicht überall - so weit ich weiß. Schon gar nicht numerisch - avrasm2 sieht da Literale (nach meiner Kenntnis). Lokale Label gibt es da auch nur in Makros - anderes ist mir nicht bekannt. Außerhalb von Makros werden Mehrfach-Labels abgewiesen.
Superprofi schrieb im Beitrag #5861232:
> Hat das überhaupt mal jemand ausprobiert?
Wie denn? Dazu fehlen zahlreiche Infos.
Stefanus F. schrieb: > Superprofi schrieb im Beitrag #5861232: >> Hat das überhaupt mal jemand ausprobiert? > > Wie denn? Dazu fehlen zahlreiche Infos. Stell dich nicht so dumm an. Nimm den Codeabschnitt, starte das Atmel Studio 7, wähle einen µC aus und assembliere die paar Zeilen des TOs:
2: rjmp 1f nop 1: rjmp 2b |
Es ist ganz leicht den TO zu bestätigen bzw. zu widerlegen. Man muss es nur wollen.
Bernd schrieb: > Stell dich nicht so dumm an. Geht es denn um den Assembler im Atmel Studio? Betrifft es denn wirklich jeden beliebigen Mikrocontroller (oder die ganze Xmega E Serie)? Also wenn sich hier jemand so laut über einen mutmaßlichen Bug beklagt, dann sollte er selbst die Forschungsarbeit machen. Ich bin doch nicht sein Diener!
> Vielleicht mache ich ja auch etwas falsch, rjmp deckt nicht auf jedem XMEGA den gesamten Programmspeicher ab. https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_RJMP.html
Bernd schrieb: > Es ist ganz leicht den TO zu bestätigen bzw. zu widerlegen. Man muss es > nur wollen. Mach mal!
Hallo, ich habe Deinen Code nun aus einem ATxmega32E5 und einem ATxmega32A4U getestet, indem ich folgenden Code aus einem einfachen Dispatcher heraus aufgerufen habe:
case 'x': USARTD0RomString(TstMsg); __asm__ __volatile__ ("rjmp .+2"); __asm__ __volatile__ ("nop"); __asm__ __volatile__ ("rjmp .-6"); USARTD0RomString(DoneMsg); break; case 'y': USARTD0RomString(TstMsg); __asm__ __volatile__ ("rjmp .+2"); __asm__ __volatile__ ("nop"); __asm__ __volatile__ ("nop"); __asm__ __volatile__ ("rjmp .-8"); USARTD0RomString(DoneMsg); break; |
Auf dem E5 führt nur der zweite Teil, also das Kommando 'y' in eine Endlosschleife, auf dem A4U beide. Grüßle Volker
Volker B. schrieb: > indem ich folgenden Code aus einem einfachen Dispatcher heraus > aufgerufen habe: Gefällt mir nicht, das ist mir zu weit vom Problembericht des TO entfernt. C hat bei diesem Test meiner Meinung nach nichts verloren. Wie sieht denn das Assembler-Listing vom Compiler-Output aus?
:
Bearbeitet durch User
Stefanus F. schrieb: > Bernd schrieb: >> Es ist ganz leicht den TO zu bestätigen bzw. zu widerlegen. Man muss es >> nur wollen. > > Mach mal! Ich will es ja nicht!
Bernd schrieb: > Stefanus F. schrieb: >> Bernd schrieb: >>> Es ist ganz leicht den TO zu bestätigen bzw. zu widerlegen. Man muss es >>> nur wollen. >> >> Mach mal! > > Ich will es ja nicht! Dann mecker nicht.
Notorischer Nachleser schrieb: >> Vielleicht mache ich ja auch etwas falsch, > > rjmp deckt nicht auf jedem XMEGA den gesamten Programmspeicher ab. > https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_RJMP.html +/- 6 Byte wird es wohl mit allen gehen. Da bin ich zuversichtlich.
>> da ich nur in Assembler programmiere Bimbo. schrieb: > Da liegt dein Problem! Interessante Argumentation. Kurz un Knapp wie ich es mag, aber leider auch vollkommen ohne Sinn. Geht es vielleicht etwas ausführlicher, dann kommt der Sinn vielleicht doch noch hinzu?
Stefanus F. schrieb: > Interessante Argumentation. Kurz un Knapp wie ich es mag, aber leider > auch vollkommen ohne Sinn. Geht es vielleicht etwas ausführlicher, dann > kommt der Sinn vielleicht doch noch hinzu? Was ist denn daran so schwer zu verstehen? ;)
Stefanus F. schrieb: > Gefällt mir nicht, das ist mir zu weit vom Problembericht des TO > entfernt. C hat bei diesem Test meiner Meinung nach nichts verloren. Sorry, aber ich schreibe jetzt nicht noch ein Assembler-Programm. > Wie sieht denn das Assembler-Listing vom Compiler-Output aus? A4U main.lss:
case 'x': USARTD0RomString(TstMsg);
2820: 84 e0 ldi r24, 0x04 ; 4
2822: 92 e0 ldi r25, 0x02 ; 2
2824: 0e 94 e2 0b call 0x17c4 ; 0x17c4 <USARTD0RomString>
__asm__ __volatile__ ("rjmp .+2");
2828: 01 c0 rjmp .+2 ; 0x282c <main+0xd4>
__asm__ __volatile__ ("nop");
282a: 00 00 nop
__asm__ __volatile__ ("rjmp .-6");
282c: fd cf rjmp .-6 ; 0x2828 <main+0xd0>
USARTD0RomString(DoneMsg);
282e: 8c ef ldi r24, 0xFC ; 252
2830: 91 e0 ldi r25, 0x01 ; 1
2832: 0e 94 e2 0b call 0x17c4 ; 0x17c4 <USARTD0RomString>
2836: d5 cf rjmp .-86 ; 0x27e2 <main+0x8a>
case 'y': USARTD0RomString(TstMsg);
2838: 84 e0 ldi r24, 0x04 ; 4
283a: 92 e0 ldi r25, 0x02 ; 2
283c: 0e 94 e2 0b call 0x17c4 ; 0x17c4 <USARTD0RomString>
__asm__ __volatile__ ("rjmp .+2");
2840: 01 c0 rjmp .+2 ; 0x2844 <main+0xec>
__asm__ __volatile__ ("nop");
2842: 00 00 nop
__asm__ __volatile__ ("nop");
2844: 00 00 nop
__asm__ __volatile__ ("rjmp .-8");
2846: fc cf rjmp .-8 ; 0x2840 <main+0xe8>
2848: f2 cf rjmp .-28 ; 0x282e <main+0xd6>
|
E5 main.lss:
6d8: 0e 94 7d 01 call 0x2fa ; 0x2fa <USARTD0RomString> 6dc: c5 cf rjmp .-118 ; 0x668 <main+0x84> 6de: 84 eb ldi r24, 0xB4 ; 180 6e0: 90 e0 ldi r25, 0x00 ; 0 6e2: 0e 94 7d 01 call 0x2fa ; 0x2fa <USARTD0RomString> 6e6: 01 c0 rjmp .+2 ; 0x6ea <main+0x106> 6e8: 00 00 nop 6ea: fd cf rjmp .-6 ; 0x6e6 <main+0x102> 6ec: 8c ea ldi r24, 0xAC ; 172 6ee: 90 e0 ldi r25, 0x00 ; 0 6f0: f3 cf rjmp .-26 ; 0x6d8 <main+0xf4> 6f2: 84 eb ldi r24, 0xB4 ; 180 6f4: 90 e0 ldi r25, 0x00 ; 0 6f6: 0e 94 7d 01 call 0x2fa ; 0x2fa <USARTD0RomString> 6fa: 01 c0 rjmp .+2 ; 0x6fe <main+0x11a> 6fc: 00 00 nop 6fe: 00 00 nop 700: fc cf rjmp .-8 ; 0x6fa <main+0x116> 702: f4 cf rjmp .-24 ; 0x6ec <main+0x108> |
avr-gcc --version: avr-gcc (GCC) 8.2.0 Leider sorgt der Optimierer hier für etwas Chaos. Ausschalten ist aber leider nicht ohne weiteres möglich, wg. Initialisierung des Oszillators. Falls der TO noch Interesse hat, möge er die gewünschten Daten liefern. Grüßle Volker
Dieter R. schrieb: > Notorischer Nachleser schrieb: >>> Vielleicht mache ich ja auch etwas falsch, >> >> rjmp deckt nicht auf jedem XMEGA den gesamten Programmspeicher ab. >> https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_RJMP.html > > +/- 6 Byte wird es wohl mit allen gehen. Da bin ich zuversichtlich. ich dachte da eher an einen möglichen Overflow im PC an Bereichsgrenzen. Und das der TO in seinem angeblichen Assembler-Compilat die absoluten adressen unterschlägt. Vielleicht ist ja auch der linker der Überltäter. Ohne Flash-dump kann man nicht sicher sagen was nun wirklich im uC passiert, die hingeworfene Fehlerbeschreibung "aber er überspringt den letzten rjmp" ist unprofessionel schlampig.
Volker B. schrieb: > Assembler Listing Da hast du genau den Fall, den der TO beschrieben hat. Es wurde offensichtlich korrekt compiliert. Es geht also tatsächlich, wie der TO schrieb, um einen hardware Bug. Bernd schrieb: > Es ist ganz leicht den TO zu bestätigen bzw. zu widerlegen. Man muss es > nur wollen. Nun hast du die Bestätigung, die du gefordert hast aber nicht selbst bringen wolltest. Nächster Schritt: Das Programm auf diversen Xmega E Controllern austesten. Das ist nicht mehr ganz so leicht, man muss die Hardware auch haben. Volker B. schrieb: > Auf dem E5 führt nur der zweite Teil, also das Kommando 'y' in eine > Endlosschleife, auf dem A4U beide. Volker, wie hast du diesen Satz gemeint? Ich verstehe ihn so, dass du das Programm tatsächlich auf einem Mikrocontroller ausgeführt hast, richtig?
Stefanus F. schrieb: > Gefällt mir nicht, das ist mir zu weit vom Problembericht des TO > entfernt. C hat bei diesem Test meiner Meinung nach nichts verloren. Der TO spricht von einen Hardware Bug. C Compiler ist Software
my2ct schrieb: > Der TO spricht von einen Hardware Bug. Es wird kein Hardware Bug vorliegen. Wenn man das ganze Projekt krirgen würde, könnte ein spitzfindiger Assemblerianer bestimmt schnell das Problem identifizieren.
Volker B. schrieb: > <USARTD0RomString> > _asm__ __volatile_ ("rjmp .+2"); > 2828: 01 c0 rjmp .+2 ; 0x282c > <main+0xd4> > _asm__ __volatile_ ("nop"); > 282a: 00 00 nop > _asm__ __volatile_ ("rjmp .-6"); > 282c: fd cf rjmp .-6 ; 0x2828 > <main+0xd0> Faszinierend. Ich würde empfehlen, beim aktuellen Stand des Wissens das bei Microchip als Bug Report einzureichen. Meine persönliche Erfahrung ist, dass man da recht schnell und kompetent Antwort bekommt. Das erspart dann auch weitere Tests mit x verschiedenen Prozessoren. Schade, dass ihr hier die Arbeit macht und sich das Großmaul wieder verdrückt hat.
Stefanus F. schrieb: > Volker, wie hast du diesen Satz gemeint? Ich verstehe ihn so, dass du > das Programm tatsächlich auf einem Mikrocontroller ausgeführt hast, > richtig? Das Programm wurde sowohl auf dem 32A4U1 als auch auf dem 32E5 getestet, wobei das Programm natürlich für jede MCU neu compiliert wurde. Beim A4U liefen beide Varianten in eine Endlosschleife, die Fertigmeldung erschien kein einziges Mal auf dem Terminal und die MCU reagierte nicht mehr auf die RS232. Beim E5 wurde die erste Variante beendet (Fertigmeldung wurde im Terminal angezeigt), Variante 2 erzeugte die vom TO gewünschte Endlosschleife, keine Reaktion mehr von der MCU. Grüßle Volker
Irgendwie finde ich dazu kein Errata Dokument. Das müsste doch hier sein, oder nicht? https://www.microchip.com/wwwproducts/en/ATxmega32e5
Stefanus F. schrieb: > Irgendwie finde ich dazu kein Errata Dokument. Das müsste doch hier > sein, oder nicht? https://www.microchip.com/wwwproducts/en/ATxmega32e5 Ist bei Atmel immer im Data Sheet, hier ab S. 143. da steht aber nichts passendes. Melden, abwarten.
Stefanus F. schrieb: > Irgendwie finde ich dazu kein Errata Dokument. Das müsste doch hier > sein, oder nicht? https://www.microchip.com/wwwproducts/en/ATxmega32e5 Im Datenblatt Atmel-8153K–AVR-ATxmega8E5-ATxmega16E5-ATxmega32E5_Datasheet–08/2016 findet sich: Rev. A * DAC: AREF on PD0 is not available for the DAC * EDMA: Channel transfer never stops when double buffering is enabled on sub-sequent channels * ADC: Offset correction fails in unsigned mode * ADC: Averaging is failing when channel scan is enabled * ADC: Averaging in single conversion requires multiple conversion triggers * ADC accumulator sign extends the result in unsigned mode averaging * ADC: Free running average mode issue * ADC: Event triggered conversion in averaging mode * AC: Flag can not be cleared if the module is not enabled * USART: Receiver not functional when variable data length and start frame detector are enabled * T/C: Counter does not start when CLKSEL is written * EEPROM write and Flash write operations fails under 2.0V * TWI master or slave remembering data * Temperature Sensor not calibrated Rev. B * DAC: AREF on PD0 is not available for the DAC * ADC: Offset correction fails in unsigned mode * EEPROM write and Flash write operations fails under 2.0V * TWI Master or slave remembering data * TWI SM bus level one Master or slave remembering data * Temperature Sensor not calibrated * Automatic port override on PORT C * Sext timer is not implemented in slave mode Grüßle Volker P.S.: Die von mir gesteste MCU hatte Mask Rev. B und Date Code 1542. Andere Mask Revs liegen mir nicht vor.
:
Bearbeitet durch User
Weiterhin könnte auch die Taktfrequenz wichtig sein. Es wäre nicht der erste AVR, der die Maximalwerte nicht schafft. Der AT90S1200 war z.B. im Datenblatt mit 20MHz angegeben, das Eval-Sample war mit 16MHz beschriftet und der Produktionstyp schaffte nur noch 12MHz. Und beim AT90S8515 blieben von den 20MHz im Datenblatt sogar nur 8MHz in der Serie übrig.
Bei den ersten Reaktionen hier braucht man mir wirklich nicht vorwerfen, mich "verzogen" zu haben. Auch wenn ich in Assembler programmiere und deshalb von vielen als Masochist angesehen werde, habe auch ich eine Schmerzgrenze. Anscheinend scheint man jetzt ja doch wenigstens mal hinschauen zu wollen, nachdem mal einer das ausprobiert hat und oh überraschung, der TO hatte Recht. Wo kommen wir denn da hin, wenn jemand, der sich Superprofi nennt, hinerher auch noch recht hat? Und dann auch noch anonym. Unverschämtheit! Hier noch einige Details: Der xmega E läuft mit dem Default Takt von 2 MHz und 3.3V. Schön zu hören, dass das Problem wohl nur beim E auftritt. Ärgerlich, dass man immer wieder reinläuft. Zumindest als Assemblerprogrammierer. Als C-Programmierer wird der Compiler wahrscheinlich Doppelsprünge direkt auflösen, aber Übersicht ist für uns wichtiger als 2 Takte zu sparen. Es wurde auch nach kompiliertem Code gefragt. Der wurde aber im Anfangsposting geliefert, direkt aus dem .lss. Ich habe jetzt bei einem Programm ganz am Anfang, also wirklich da, wo die Interruptvektoren stehen, den Problemcode gespeichert. Das eigentliche Programm (Blinklicht, irrelevant für das Thema) dürfte also nie ausgeführt werden. Trotzdem wird es das. Hier das .lss:
main.elf: file format elf32-avr Disassembly of section .text: 00000000 <__ctors_end>: 0: 01 c0 rjmp .+2 ; 0x4 <Agreen_seg_5> 2: 00 00 nop 4: fd cf rjmp .-6 ; 0x0 <__ctors_end> 6: 00 00 nop 8: 0c 94 52 00 jmp 0xa4 ; 0xa4 <main> c: 0c 94 37 02 jmp 0x46e ; 0x46e <isr_unusedint> ... |
Haben die Herren sonst noch Wünsche?
Superprofi schrieb: > Es wurde auch nach kompiliertem Code gefragt. Der wurde aber im > Anfangsposting geliefert, direkt aus dem .lss. Also mir fehlt immer noch der vollständige Hex-dump. Schau, zu einem ausführbares Programm gehören zwei, der Instruction code und die Addresse desselben. Gerade für Sprünge, weil nur mit diesen beiden Angaben kann man die Arbeit des Programm counters wirklich nachvollziehen, also schaun was PC_neu <= PC + IPCode(k-offset) wirklich tut. Mit einem Hexdump könnte man das ganze auch in einen HDL-Simulator stopfen und das ganze auf Gatterebene nachvollziehen. Und es ist immer noch nicht klar, wohlin der Prozessor nun wirklich springt. Und ob er zweimal springt oder einmal und dann knallt ein Trap-IRQ rein. Wobei ich jetzt eher auf das Problem "Doppelsprung" bei Carry-bildung tippe. Also der PC muss hintereinander addieren und subtrahieren. Carries werden gern gepiplined um die Taktfrequenz hoch zu halten, da kann der IC-Designer schonmal einen Fehler gemacht haben, oder eben die Einschränkung "keine Doppelsprünge wchselnder Richtung" in die Spec für den Compiler-bauer und assembler-Rule-Checker geschrieben haben, was der dann aber übersah und noch nicht seinen Weg in die Anwenderdokumentation fand. Was IMHO auch noch nicht berücksichtigt wurde ist die Zweiteilung des FLASH in Bootloader und Application Anteil. Im Manual findet sich dazu der Satz "The sizes of the different sections are fixed, but device-dependent." Das ist zumindest ein Hinweis auf unterschiedliches Verhalten für A und E Typen. Es sollte also untersucht werden ob das Verhalten von der Location im Flash abhängig ist, Und dazu braucht es wiedermal die absoluten Addressen.
Superprofi schrieb: > Haben die Herren sonst noch Wünsche? Ja. Erzähl das Ganze Microchip: https://microchipsupport.force.com/s/article/How-to-submit-a-case und dann erzähl uns hinterher, was Microchip herausgefunden und geantwortet hat.
Notorischer Nachleser schrieb: > Wobei ich jetzt eher auf das Problem "Doppelsprung" bei Carry-bildung > tippe. Also der PC muss hintereinander addieren und subtrahieren. Er springt im Beispiel ja bloß, ohne jede Auswertung von Flags. Aber irgendwas mit Prefetch liegt irgendwie nahe. Dann kommt letztlich so etwas heraus, wie du vermutest, nämlich eine Einschränkung für den Assembler/Compiler-Bauer. Da hilft aber kein Rätselraten, das sollte Microchip beantworten.
Suportprofi, offensichtlich hast du den relevanten Code auf ein Minimum reduziert. Das ist auf jeden Fall lobenswert. Zwei Sachen sind hier schief gelaufen: a) Einige Leute waren sich unsicher, ob es um eine Hardwarefehler oder um einen Fehler im Asembler geht. Ich gehöre dazu. Wie das passieren konnte, ist mir im Nachhinein unklar, denn dein Text war diesbezüglich eindeutig. b) Es fehlt die Nachvollziehbarkeit. Also eine Beschreibung, mit welchem Setup man das reproduzieren und den vollständigen Quelltext. Es ist nämlich gerade bei solchen Bugs sehr häufig so, dass er nur unter ganz bestimmten Rahmenbedingungen zutage tritt. Dass ein AVR Mikroocntroller (der auf 20 Jahre Historie blickt) bei einem popeligen rjmp unabhängig vom Kontext immer falsch springt, scheint zunächst so unwahrscheinlich, wie beim Kacken vom Blitz getroffen zu werden. Diesbezüglich fällt mir dieser unterhaltsame Vortrag von David Kriesel ein, der ist auch auf so einen Bug gestoßen, den es eigentlich nicht geben dürfte: Youtube-Video "David Kriesel: Traue keinem Scan, den du nicht selbst gefälscht hast" David hat in seinen Vortrag Ratschläge einfließen lassen, wie man mit solchen Situationen umgehen soll. Unter anderem: - Zuerst versuchen, den Sachverhalt mit dem Hersteller zu klären. Nicht gleich öffentlich werden. - Wenn der Hersteller nicht mitmacht, dann öffentlich gehen. Aber gleich unwiederlegbare nachvollziehbare Beweise mit bringen. - Immer sachlich und höflich bleiben. Ich denke, da kann man Dir keinen Vorwurf machen. Ich wollte es nur mal erwähnen, da das hier öfters vergessen wird (auch von mir).
- Wird der 2. Befehl immer übersprungen? (Vermutlich nicht, das hätten sie gemerkt.) - Wird der 2. Befehl nur übersprungen wenn es ein rjmp -x ist? Oder auch bei +x? - Wirkt sich das NOP aus? Also: NOP durch was anderes ersetzen, bzw. durch nix. Passiert dann das gleiche? - Wie isses mit absoluten Sprüngen? Haben die das auch? also rjmp-nop-jmp = jmp wird nicht gemacht? Richtungsunabhängig? wie ist jmp-nop-jmp und jmp-nop-rjmp? - Funktioniert der Bug auch mit anderen Weiten als +2 & -6 fehlerhaft?
Superprofi schrieb: > Es wurde auch nach kompiliertem Code gefragt. Der wurde aber im > Anfangsposting geliefert, direkt aus dem .lss. nein.
Stefanus F. schrieb: > b) Es fehlt die Nachvollziehbarkeit. Also eine Beschreibung, mit welchem > Setup man das reproduzieren und den vollständigen Quelltext. Aus Hardwaresicht macht es sich bei Reproduzierbarkeit leichter, wenn -der genaue Typ (inkl. Package) genannt wird, bei dem fehler auftritt -dasgleiche, für getestet Typen, bei denen der Fehler nicht auftritt -die "Hardwareumgebung" (Takt, Voltage an Pins, ungefähre Umgebungstemperatur,programmeranschluss) beschrieben wird. aus Softwaresicht wäre der komplette Source und script hilfreich, ggf. Flash-file, so dass man das ganze ggf. schnell ausprobieren kann. Bei dem Komplettsourcen interessiert u.a. beispielsweise wie die Lockbits für Boot-segment o.ä. per default stehen. Und immer vorsicht mit einer eigenen Klassifikation als "Bug" oder gar "kritischer Bug". Oft ist ein Bug in wirklichkeit ein Feature das seinen Weg noch nicht in die Doku gefunden hat. Und manchmal findet es der Hersteller "vertretbar", wenn das Feature garnicht in der Doku beschrieben wird, sondern allein die Hersteller-tools/compiler davon wissen und "transparente" workarounds bei der Compilierung ausführen. -- Ich hab mal weiter die CPU-Architektur auf mögliche Erklärungen abgeklopft. -RJMP benutzt einen 12 bit offset der als 2'er Komplement realisiert ist. Damit kann man 2047 addressen vor oder 2048 addressen zurück springen. der Bootloader ist wohl 4kbyte tief also 2048 Addressen. (Bem.: durch das 2'er komplement wird das zurückspringen wohl als Addition auf den PC mit Überlauf realisiert. -derPC ist bei den Prozessoren breiter als 12 Bit, bei einem Überlauf ist also zu unterscheiden ob eine Segementüberschreitung ins nächste Segment oder ein Rückwartssprung beabsichtigt ist. -das pipeling ist (lt. Doku) wohl bei allen untersuchten typen gleich (single-stage) -Ebenso die Speichertiefe und -aufteilung
Bernd K. schrieb: > Superprofi schrieb: >> Es wurde auch nach kompiliertem Code gefragt. Der wurde aber im >> Anfangsposting geliefert, direkt aus dem .lss. > > nein. Der TO hat aber Teile davon am Ende von Beitrag "Re: XMEGA Hardware-Bug (Kritisch)" als dissassembliertes .elf nachgeliefert. Anhand desen kann man schon mal die korrekte codierung der OP-codes nachprüfen.
Notorischer Nachleser schrieb: > -derPC ist bei den Prozessoren breiter als 12 Bit, bei einem Überlauf > ist also zu unterscheiden ob eine Segementüberschreitung ins nächste > Segment oder ein Rückwartssprung beabsichtigt ist. Wo ist was von segmentierter Architektur dokumentiert? Die Begrenzung des RJMP ist doch bloß der Erfordernis geschuldet, dass der Opcode in ein Word passen muss. Ich kann mir nicht vorstellen, dass dies Einfluss auf die PC-Berechnung hat. Es sei denn, als Hardware-Bug. Aber wir sollten eigentlich alle das spekulieren lassen. Da ist Atmel gefragt.
Da Beitrag "Re: XMEGA Hardware-Bug (Kritisch)" werden unterschiedliche segmente benutzt. Das untere Listing spielt im 0x0600 Adressbereich, es werden also weniger als 12 addressbits gesetzt, während das obere im Bereich x2800 spielt, also 14 addressbits benutzt werden. Das kann relevant sein, da RJMP nur einen 12 bit 2'er komplement offset mitbringt.
Notorischer Nachleser schrieb: > Bernd K. schrieb: >> Superprofi schrieb: >>> Es wurde auch nach kompiliertem Code gefragt. Der wurde aber im >>> Anfangsposting geliefert, direkt aus dem .lss. >> >> nein. > > Der TO hat aber Teile davon am Ende von > Beitrag "Re: XMEGA Hardware-Bug (Kritisch)" > als dissassembliertes .elf nachgeliefert. > Anhand desen kann man schon mal die korrekte codierung der OP-codes > nachprüfen. Also, ich sehe Maschinencode erstmalig bei Autor: Volker B. (Firma: L-E-A) (vobs) Datum: 01.06.2019 11:19 Der Superprofi kam erst am nächsten Tag damit rüber. Bis zum Posting von Volker war der Verdacht eines Assembler-Problems nicht so fernliegend, insbesondere angesichts der Tatsache, dass hier eine Konstruktion verwendet wurde, die eigentlich für Makros gedacht ist.
Dieter R. schrieb: > Notorischer Nachleser schrieb: > >> -derPC ist bei den Prozessoren breiter als 12 Bit, bei einem Überlauf >> ist also zu unterscheiden ob eine Segementüberschreitung ins nächste >> Segment oder ein Rückwartssprung beabsichtigt ist. > > Wo ist was von segmentierter Architektur dokumentiert? Im Manual section 4.3.
Notorischer Nachleser schrieb: > Da Beitrag "Re: XMEGA Hardware-Bug (Kritisch)" > > werden unterschiedliche segmente benutzt. > Segment != segmentierte Architektur. Ich weiß es nicht, ich frage. Meine Kenntnis dieser Prozessoren ist nicht so tiefgehend. Segmentierte Architektur hatten (haben) z. B. Intel x86. Mein nicht besonders fundierter Kenntnisstand ist, dass ARM zwar je nach Implementierung Pages kennt, aber keine Segmentierung. Im Manual section 4.3. steht genau nichts darüber, sondern was über Speicherbereiche. Das hat nichts mit der Prozessorarchitektur zu tun.
:
Bearbeitet durch User
Dieter R. schrieb: > Notorischer Nachleser schrieb: >> Da Beitrag "Re: XMEGA Hardware-Bug (Kritisch)" >> >> werden unterschiedliche segmente benutzt. > Im Manual section 4.3. steht genau nichts darüber, sondern was über > Speicherbereiche. Das hat nichts mit der Prozessorarchitektur zu tun. Da steht "The flash memory is organized in two main sections, the application section and the boot loader section ... These two sections have separate lock bits, and can have different levels of protection. " Section ist zwar nicht das gleiche Wort wie Segment, bezeichnet aber bzgl. Addressbereich das selbe. Vielleicht wird es mit der Skizze am Ende von: https://www-user.tu-chemnitz.de/~heha/viewchm.php/hs/ATmegaX8.chm/bref/adressierungsarten.htm klarer. Das potentielle Problem in dieser Architektur steckt in der Addition einer 16 bit mit einer 12 bit zweier Komplenetzahl. k muss um 4 oberer bits korekt ergänzt werden damit die 2'er Komplementaddition auch korrekt "rückwärts" erfolgt. Falls das nicht korrekt erfolgt, kann der sprung in die falsche Richtung gehen und/oder ein Hardware-Trap ausgelöst werden, da die unterschiedlichen section/segements unterschiedliche Schutzlevel haben können - "These two sections have separate lock bits, and can have different levels of protection." Gerade die unterschiedlichen Schutzebenen gehen über die simple Unterteilung in "Bereiche" hinaus und kann schon als "section/segment" benannt werden.
Notorischer Nachleser schrieb:
5 x nein. Hat alles nichts mit der Prozessorarchitektur zu tun und er
springt nicht in unterschiedlichen Speicherbereichen. Die Ergänzung von
12 auf 16 Bit ist eine solche Trivialität, dass da schwerlich ein
Problem liegen sollte. Adressbereich und Segment ist auch nicht
dasselbe. Lass doch den Superprogrammierer bei Microchip fragen, dann
erfahren wir (vielleicht) mehr.
Dieter R. schrieb: > Notorischer Nachleser schrieb: > > 5 x nein. Hat alles nichts mit der Prozessorarchitektur zu tun und er > springt nicht in unterschiedlichen Speicherbereichen. Die Ergänzung von > 12 auf 16 Bit ist eine solche Trivialität, dass da schwerlich ein > Problem liegen sollte. Adressbereich und Segment ist auch nicht > dasselbe. Da will ein Softwerker einem Hardwerker und Prozessorbauer erklären was Hardware-architektur ist und was nicht... Na dann schau ich mal weiter amüsiert zu wie Softwerker über Hardware-bugs spekulieren und halt ansonsten die Füße still. > Lass doch den Superprogrammierer bei Microchip fragen, dann > erfahren wir (vielleicht) mehr. Jajaja "Super-Programmierer", alles super: Youtube-Video "Dea Werbung Super Ingo 1999"
Notorischer Nachleser schrieb: >> Lass doch den Superprogrammierer bei Microchip fragen, dann >> erfahren wir (vielleicht) mehr. > > Jajaja "Super-Programmierer", alles super: > Youtube-Video "Dea Werbung Super Ingo 1999" superlanges Wochenende, superlanges Warten, superlangeweile, superrambazamba am Montag.. (besser erst am Dienstag mailen..)
Jens M. schrieb: > - Wird der 2. Befehl immer übersprungen? (Vermutlich nicht, das hätten > sie gemerkt.) ob einer was merkt oder vor dem Verkauf verändert wird sind zwei verschiedene Dinge. TomTom Navi SW auf winCE und auch auf der verkauften Hardware, die Sprachausgabe einer rechts-links Abbiege Kombi unterdrückte das erste "rechts abbiegen" so kam es das man nur hörte "links abbiegen" und sofort danach "bitte wenden". Angeblich hatte das niemand zuvor gemerkt, ich konnte das nie glauben!
Notorischer Nachleser schrieb: > Da will ein Softwerker einem Hardwerker und Prozessorbauer erklären was > Hardware-architektur ist und was nicht... Und wo ist jetzt der Sprung über Segmentgrenzen samt Hardware-Trap im Code von Volker B.? Du bist sowas von auf dem Holzweg, auch bei deiner Vermutung über meinen fachlichen Hintergrund.
Dieter R. schrieb: > Notorischer Nachleser schrieb: > >> Da will ein Softwerker einem Hardwerker und Prozessorbauer erklären was >> Hardware-architektur ist und was nicht... > > Und wo ist jetzt der Sprung über Segmentgrenzen samt Hardware-Trap im > Code von Volker B.? In einer der Ausführungen die du mit einem Fünffachen Nein weggebügelt hast. > Du bist sowas von auf dem Holzweg, auch bei deiner Vermutung über meinen > fachlichen Hintergrund. Naja Deine Auslassungen lassen nicht den Schluss zu das, Du Erfahrungen hast aus einer stückhaften Schilderung des Fehlerbildes, Hypothesen über potentielle kausale Ursachen in der Hardware aufzustellen. PS: Ich bin raus, endgültig. Erst Interesse an Erklärungen heucheln, anschliessend niederbrüllen. Für Kindergarten ist mir meine Freizeit zu schade.
Notorischer Nachleser schrieb: >> Und wo ist jetzt der Sprung über Segmentgrenzen samt Hardware-Trap im >> Code von Volker B.? > > In einer der Ausführungen die du mit einem Fünffachen Nein weggebügelt > hast. Ist wohl doch zu hoch für mich. 6e6: 01 c0 rjmp .+2 ; 0x6ea <main+0x106> 6e8: 00 00 nop 6ea: fd cf rjmp .-6 ; 0x6e6 <main+0x102> Der Code ist ja durchaus überschaubar. Ich seh da keine "Segment"grenze oder irgendwas, was bei der PC-Berechnung daneben gehen könnte. Da der Notoriker jetzt raus ist - kann es mir jemand anders erklären? Ich hab kein Problem damit, eigene Irrtümer zuzugeben und würde es wirklich gerne wissen, wenn denn an der Argumentation was dran sein sollte.
Superprofi schrieb: > 2: > rjmp 1f > nop > 1: > rjmp 2b > > Kompiliert zu: > > rjmp .+2 > nop > rjmp .-6 Dieter R. schrieb: > Ich seh da keine "Segment"grenze > oder irgendwas, was bei der PC-Berechnung daneben gehen könnte. im original Posting gibt es noch keine Adressen, da könnte durchaus was über "Segmentgrenzen" passieren! schon beim Quellcodewechsel vom m328p zu 1284p lief bei fastLED was schief, die Ausführungsdauer war 10% größer weil der m1284p ein zusätzliches Adressbyte benötigte was die delay.h verfälschte! Beitrag "Arduino FastLED LIB vs. WS28xx LIB" Lösung: Beitrag "Re: Arduino FastLED LIB vs. WS28xx LIB"
:
Bearbeitet durch User
Im zuletzt geposteten .lss stehen die absoluten Adressen drin und die fängt bei 0 an. Nix mit Segment Jump. Das ist schlicht und einfach ein knallharter Hardware Bug. Der ist so banal, da braucht man gar nicht gross vorsichtig beim Rausrufen zu sein. Der xmega E ist sowieso eine Weiterentwicklung der anderen xmegas. Wenn man ernsthaft damit arbeitet, sieht man, dass da viele Dinge aufgebohrt und verbessert wurden. Das war bestimmt ein Testballon, bevor man neue Tausendfüssler mit diesem Core baut. Leider wurde daraus ja aus bekannten Gründen nichts mehr..... Ich tippe auf einen Bug im Pipelining. Das drängt sich zumindest auf. Man könnte jetzt analysieren, ob es auch andere Konstellationen gibt, in denen das Problem auftritt. Oder man ignoriert das ganze einfach und flamet noch n bissl rum... Ehrlich gesagt bin ich überrascht, dass heutzutage anscheinend wirklich fast keiner mehr Assembler programmiert, oder zumindest keiner mehr in Kombination mit den xmegas. Ich zumindest schreibe so ein Testprogramm schneller, als mich gross drüber aufzuregen, was es alles sein könnte. Ergo kann es nur so sein, dass fast jeder hier für sowas nicht die Ausrüstung hat und deshalb das Rumspekulieren wiederum schneller geht, als das mal eben kurz selber ausprobieren.
Superprofi schrieb: > Ich tippe auf einen Bug im Pipelining. Das drängt sich zumindest auf. Ich tippe auf einen Schwätzer. Das drängt sich zumindest auf. In welcher Umgebung (mit welchem Assembler, Makefile etc.) hast Du assembliert? Ist das Beitrag "XMEGA Hardware-Bug (Kritisch)" im oberen Teil das komplette Programm - oder ein Makro?
OssiFant schrieb: > Superprofi schrieb: >> Ich tippe auf einen Bug im Pipelining. Das drängt sich zumindest auf. > > Ich tippe auf einen Schwätzer. Das drängt sich zumindest auf. > > In welcher Umgebung (mit welchem Assembler, Makefile etc.) hast Du > assembliert? > > Ist das Beitrag "XMEGA Hardware-Bug (Kritisch)" im > oberen Teil das komplette Programm - oder ein Makro? Wie dumm bist du eigentlich? Wenn ich dir ein .lss gebe, dann spielt der Compiler keine Rolle mehr! Du hast KEINE AHNUNG und merkst es nichtmal, prollst hier aber rum wie ein Superprofi. Hier noch ein Bindump mit Offset 0. Aber du fragst jetzt sicher, was das für eine Programmiersprache ist. 01 C0 00000001 11000000 00 00 00000000 00000000 FD CF 11111101 11001111
Superprofi schrieb: > Das ist ja wie Katzen das 1x1 zu erklären. Erklärt hast Du gar nichts - nur verschleiert. Aber gut, dass Du raus bist, dann kann das Thema ja geschlossen werden.
Superprofi schrieb: > Wie dumm bist du eigentlich? Wenn ich dir ein .lss gebe, dann spielt der > Compiler keine Rolle mehr! Wenn Du mal den Unterschied zwischen Compiler und Assembler verstehst bist Du schon einen Schritt weiter.
Ok, ich fasse mal zusammen: Problematische Sequenz:
01 C0 00000001 11000000 ; rjmp .+2 00 00 00000000 00000000 ; nop FD CF 11111101 11001111 ; rjmp .-6 |
* Artefakt: Das 2. RJMP wird nicht (immer) ausgeführt. * Saftware-Kontext: Geschieht auch unmittelbar nach Reset, keine IRQs erforderlich. * Device: ATXmega32E5. Produktion: 1542 (KW42 2015). Package: ? * Takt: 2MHz (intern?), Fuses: ? * VCC: 3.3V * Temperatur: ? Das sollte für den Hersteller ersma genug Info sein, um das in Hardware nachvollziehen zu können; immerhin konnte Volker den Bug ohne große Mühe bestätigen. Und je nachdem, wie genau deren Hardware-Simulation ist, gibt's dann vielleicht auch mehr Info zu den genauen Bedingungen / Befehlssequenzen, in denen der Bug auftreten kann. Bisher ist AVR ja ziemlich verschont von Core-Bugs, der einzig mir bekannte ist der Skip-Bug in uralt-AVRs, für den den Compiler recht einfach Work-Arounds einfügen kann. Bei dem vorliegenden Bug wäre das nur auf Assembler-Ebene möglich. Superprofi schrieb: > Das ist ja wie Katzen das 1x1 zu erklären. Vielleicht haben die Experten ja inzwischen verstanden, dass ein Silicon-Bug nix mit Coding-Style zu tun hat :-)
Package: TQFP Temperatur: 25 Grad (Was sonst? Perverse Bedingungen hätte ich natürlich genannt.) Fuses: Default Takt: 2 MHz Intern Das ganze spielt aber doch gar keine Rolle. Jemand, der so einen Bug vor sich haben will, nimmt sich einen xmega E und probiert es aus. Erst wenn er NICHT auftritt, würde ich nach Infos fragen.
Superprofi schrieb: > Ehrlich gesagt bin ich überrascht, dass heutzutage anscheinend wirklich > fast keiner mehr Assembler programmiert Alles persönliche Präferenz ... Früher hab ich alles in Assembler geschrieben, aber der avrgcc ist so gut, dass das - meiner Meinung nach - einfach nicht mehr notwendig ist. Genauso wie du irritiert bist, dass niemand mehr Assembler programmiert, sind andere irritiert, weil es noch Menschen gibt, die in Assembler programmieren. Es gibt hier kein Richtig oder Falsch - es sind alles nur Meinungen.
:
Bearbeitet durch User
Superprofi schrieb: > Im zuletzt geposteten .lss stehen die absoluten Adressen drin und die > fängt bei 0 an. Nix mit Segment Jump. du verstehst es einfach nicht: der Block Superprofi schrieb: > 2: > rjmp 1f > nop > 1: > rjmp 2b > > Kompiliert zu: > > rjmp .+2 > nop > rjmp .-6 könnte ja irgendwo im gesamten Code stehen, am Ende von langen Quellcodes also auch kurz vor Segmentgrenzen! Deswegen ist er hier ja ohne Adressen gezeigt! Relokatiblen Code hatte ich auch schon 1984 am PC 1500 gemacht, einfach weil ich mich nicht festlegen wollte wo meine SW im EEPROM landet!
:
Bearbeitet durch User
Joachim B. schrieb: > Superprofi schrieb: >> Im zuletzt geposteten .lss stehen die absoluten Adressen drin und die >> fängt bei 0 an. Nix mit Segment Jump. > > du verstehst es einfach nicht: "Zuletzt gepostet" in Bezug auf den von dir zitierten Beitrag ist: Beitrag "Re: XMEGA Hardware-Bug (Kritisch)" und da steht u.a.:
> main.elf: file format elf32-avr > > Disassembly of section .text: > > 00000000 <__ctors_end>: > 0: 01 c0 rjmp .+2 ; 0x4 <Agreen_seg_5> > 2: 00 00 nop > 4: fd cf rjmp .-6 ; 0x0 <__ctors_end> > ... > |
also ab Adresse 0 und mit Disassembly und Maschinencode.
:
Bearbeitet durch User
Johann L. schrieb: > also ab Adresse 0 und mit Disassembly und Maschinencode. ein doofes Beispiel ist nun mal kein gutes allgemeingültiges Beispiel. Was bei Adresse 0 klappt muss nicht überall klappen! schon mal gar nicht rjump -6 Beitrag "Stromunfall mit Knopfbatterien!" :)
:
Bearbeitet durch User
Superprofi schrieb: > > Das ganze spielt aber doch gar keine Rolle. Jemand, der so einen Bug vor > sich haben will, nimmt sich einen xmega E und probiert es aus. Erst wenn > er NICHT auftritt, würde ich nach Infos fragen. Du überschätzt die Wichtigkeit deiner Worte, und zwar kolossal. Jemand, der so einen Beitrag vor sich sieht wie deinen ersten, der fragt erst mal nach weiteren Informationen, bevor er sich näher mit dem Thema befasst. Aus diesem Missverständnis in deinem eigenen Selbstverständnis resultiert die ganze elend lange Diskussion. Das sollte dir zu denken geben und wäre vermeidbar gewesen, wenn du auf Nachfragen präzise geantwortet hättest. Aber nun wissen wir das ja alles, und es ist an dir, den Bug bei Microchip zu melden. Bitte informiere uns, wenn du von dort Antwort hast.
Bernd schrieb: > Johann L. schrieb: >> 4: fd cf rjmp .-6 > Und wo bitteschön soll der Core bei 4 - 6 hinspringen? Jetzt bitte nicht wieder die ganze Diskussion von vorne. Hab ich mich erst auch gefragt, aber die einfache Antwort ist offensichtlich, dass er nach 6-6 springt. Das ist auch logisch. Siehe .+2, wo springt er wohl hin bzw. soll er hinspringen, das war ja das Thema?
:
Bearbeitet durch User
Beitrag #5863274 wurde vom Autor gelöscht.
Joachim B. schrieb: > Johann L. schrieb: >> also ab Adresse 0 und mit Disassembly und Maschinencode. > > ein doofes Beispiel ist nun mal kein gutes allgemeingültiges Beispiel. > Was bei Adresse 0 klappt muss nicht überall klappen! Deshalb auch das Disassembly. Ist doch genau das, was (zu Recht) gefordert wurde? Außerdem hat Volker das Artefakt für eine andere Adresse nachvollzogen. Und Code ab 0x0 hat den Vorteil, dass unmittelbar klar ist, dass sich die Hardware bei Codestart direkt nach dem Reset befindet, also keine Interrupts freigeschaltet, keine Hardware konfiguriert, etc. Ist für Nachvollziebarkeit doch ideal! > schon mal gar nicht rjump -6 Das hat auch niemand geschrieben, bitte zitier korrekt! Da steht: > 4: fd cf rjmp .-6 ; 0x0 <__ctors_end> Man beachte das ".", was in Binutils für die aktuelle Position steht, hier also für 4 (in Einheiten von Bytes). Und "u" war da auch keins... Das Argument von RJMP ist k=0xffd, also k=-3. RJMP ersetzt PC durch PC + k + 1 (siehe AVR Instruction Manual, Einheit dort ist Words), also durch (Word)adresse 4/2 - 3 + 1 = 0. objdump rechnet die absolute Adresse sogar für dich aus, allerdings als Byte-Adresse: 0x0. Wegen dem "+1" in der Semantik von RJMP bezieht sich "." effektiv auf die Adresse 1 Word nach dem RJMP, daher also ".-6" Bytes (Binutils verwendet Byte-Adressen) für den Offset, so dass der von objdump angezeigte Offset einfach das Doppelte von k ist.
:
Bearbeitet durch User
Dieter R. schrieb: > Bernd schrieb: >> Johann L. schrieb: >>> 4: fd cf rjmp .-6 >> Und wo bitteschön soll der Core bei 4 - 6 hinspringen? > > Jetzt bitte nicht wieder die ganze Diskussion von vorne. Hab ich mich > erst auch gefragt, aber die einfache Antwort ist offensichtlich, dass er > nach 6-6 springt. Das ist auch logisch. Bestimmt bereue ich diese Rückkehr in den Thread, aber sei's drum: Es geht nicht nach logic sondern nach Datenblatt/Manual und da steht bei RJMP: PC <- PC + 1 + k der PC ist 16 bit breit, k 12 bit, die 1 wird als 16 bit gerechnet (counter-increment) http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42005-8-and-16-bit-AVR-Microcontrollers-XMEGA-E_Manual.pdf S. 432 Wo sich k im IPCODE befindet kann man http://ww1.microchip.com/downloads/en/devicedoc/atmel-0856-avr-instruction-set-manual.pdf S. 142 entnehmen Im PC stehen word-addresses, während im Listing byteaddressen stehen Es wird also ausgeführt 0 -> PC = 0x0000: 01 c0 -> IPCode 0xC001 -> RJMP 0x001 -> PC = 0x0000 + 0x0001 + 0x001 = 0x0002 nächster Befehl steht bei der word/bytaddresse 0x0002/0x0004 2 -> PC = 0x0001: 00 00 IPCODE 0x0000 -> NOP 4 -> PC = 0x0002: fd cf -> IPCode 0xCFFD -> RJMP 0xFFD -> PC = 0x0002 + 0x0001 + 0xFFD = 0x1000 ; Da wird nicht "6-6" gerechnet sondern "x0002 + xFFD + 0x001", das nennt man 2'er-komplement und das hat den Sinn, das man die Subtraktion auf Addition negativer Zahlen zurückführt. Wenn die beiden Summanden gleiche bitlänegen haben, passt das auch wunderbar, da das obere bit ohnehin weggeschnitten wird. Bei der Konstallation hier mit unterschiedlichen Bitlängen dagegen muss man es entweder dediziert löschen (verwerfen) oder den kürzeren Operanden links mit den signbits auffüllen (Vorzeichenerweiterung) https://de.wikipedia.org/wiki/Zweierkomplement#Addition_und_Subtraktion Und bei dieser PC-berechnung scheint es zu Problemen zu kommen, die Vermutung unsauber implementiertes Pipelining wurde ja bereits mehrfach geäußert. Es könnte auch ein Glitch auftreten, ein kurzes "Flackern" des PC's mit 0x1000 innerhalb eines Taktes. Ob das einstufige Pipeling die Ursache ist, könnte man mit unterschiedlicher Anzahl von NOP's zwischen den beiden RJMP's testen. Und natürlich wäre es interessant zu wissen wie es sich bei RCALL verhält.
Ich seh grad Gljade war schneller, seine Beschreibung deckt sich aber mit meiner. Und Nomen est nomen, es zahlt sich aus notorisch nachzulesen, und nicht einfach rausposaumenen, da wäre der logic nach 6-6 und alles andere sind Holzwege ....
Wie kann ich das denn nun nachvollziehen? Habe avr-as und acra auf der Platte:
$ cat rjmptest.asm .org 0x000 hier: rjmp dort nop dort: rjmp hier $ avr-as -mmcu avrxmega2 -als rjmptest.asm GAS LISTING rjmptest.asm page 1 1 .org 0x000 2 hier: 3 0000 00C0 rjmp dort 4 0002 0000 nop 5 dort: 6 0004 00C0 rjmp hier GAS LISTING rjmptest.asm page 2 DEFINED SYMBOLS rjmptest.asm:2 .text:0000000000000000 hier rjmptest.asm:5 .text:0000000000000004 dort NO UNDEFINED SYMBOLS |
Beitrag #5863330 wurde von einem Moderator gelöscht.
@Bernd: Nach dem Code z.B. noch ein Pin triggern. Das sollte dann ja nie passieren. Dann auf einen xmega E raufladen und laufen lassen.
Bernd schrieb: > Wie kann ich das denn nun nachvollziehen? > Habe avr-as und acra auf der Platte: > [avrasm] > $ cat rjmptest.asm > .org 0x000 Lass das .org weg wenn du Binutils verwendest, das macht nicht das, was du erwartest. > $ avr-as -mmcu avrxmega2 -als rjmptest.asm Das assembliert nur, erzeugt also ein Object-File aber nix Ausführbares; zusätzlich muss gelinkt / lokatiert werden. Am einfachsten geht das, indem man avr-gcc als Treiber verwendet, z.B.:
$ avr-gcc -x assembler rjmptest.asm -o rjmptest.elf -mmcu=atxmega32e5 -nodefaultlibs -nostartfiles |
Ist doch egal, was der xte mega macht. Wer die Dinger nimmt, ist selbst schuld. Atmel ist auf arm umgestiegen und tut nur noch das nötigste für die alten Avrs. So will es Microchips.
Johann L. schrieb: > Das assembliert nur, erzeugt also ein Object-File aber nix Ausführbares; > zusätzlich muss gelinkt / lokatiert werden. Am einfachsten geht das, > indem man avr-gcc als Treiber verwendet, z.B.: > $ avr-gcc -x assembler rjmptest.asm -o rjmptest.elf -mmcu=atxmega32e5 > -nodefaultlibs -nostartfiles Ah, danke. Das sieht besser aus:
$ avr-objdump -h -S rjmptest.elf rjmptest.elf: file format elf32-avr Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000006 00000000 00000000 00000074 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000000 00802000 00000006 0000007a 2**0 CONTENTS, ALLOC, LOAD, DATA Disassembly of section .text: 00000000 <__ctors_end>: 0: 01 c0 rjmp .+2 ; 0x4 <dort> ... 00000004 <dort>: 4: fd cf rjmp .-6 ; 0x0 <__ctors_end> |
Morgen schau ich mal, ob ich ein Evalboard mit XMega finde...
Bernd schrieb: > $ avr-objdump -h -S rjmptest.elf > [...] > 00000000 <__ctors_end>: > 0: 01 c0 rjmp .+2 ; 0x4 <dort> > ... > > 00000004 <dort>: Hier disassembliert man besser mit zusätzlich -z, so dass Nullen (hier: NOP) disassembliert werden anstatt als ... dargestellt.
Johann L. schrieb: > Bernd schrieb: > >> $ avr-objdump -h -S rjmptest.elf >> [...] >> 00000000 <__ctors_end>: >> 0: 01 c0 rjmp .+2 ; 0x4 <dort> >> ... >> >> 00000004 <dort>: > > Hier disassembliert man besser mit zusätzlich -z, so dass Nullen (hier: > NOP) disassembliert werden anstatt als ... dargestellt. Schön wäre es, wenn der OPcode als ein 16-bit Wert dargestellt würde und nicht als zwei mit space getrennte 8-bit Werte. Also: 0: C001 rjmp .+2 ; 0x4 <dort> Ohne das muss man beim Lesen die Bytes"im Kopf tauschen" um den instruction code wie im AVR Instruction set manual dargestellt vor sich zu haben.
Johann L. schrieb: > Da steht: > >> 4: fd cf rjmp .-6 ; 0x0 <__ctors_end> > > Man beachte das ".", was in Binutils für die aktuelle Position steht, > hier also für 4 (in Einheiten von Bytes). Und "u" war da auch keins... Kleine Korrektur für die Korithenkacker :-) und das Archiv: Der Punkt steht für die Adresse 4+2 also 6. Sonst würde ein rjmp .+0 in eine Endlosschleife führen. Statt dessen macht der aber genau gar nichts, ausser zwei Taktzyklen zu verbrauchen. Grüßle Volker
Nixmega schrieb: > Atmel ist auf arm umgestiegen und tut nur noch das nötigste für > die alten Avrs. So will es Microchips. Da tut sich doch einiges bei den neuen ATtinys und auch der ATmega328PB ist ganz nett. Fehlt nur noch der Schritt zum ATmega328PC mit 2 * CAN. Die kastrierten ATtinys mit 16 Registern scheint man glücklicher Weise nicht mehr weiter zu entwicklen.
Mampf F. schrieb: > Früher hab ich alles in Assembler > geschrieben, aber der avrgcc ist so gut, dass das - meiner Meinung nach > - einfach nicht mehr notwendig ist. Ja, die Zeiten, wo ich einen ATtiny12 programmierte sind schon lange vorbei. Und bei >1kB verliert man in Assembler schnell den Überblick.
Peter D. schrieb: > Und bei >1kB verliert man in Assembler schnell den Überblick. Ja es stimmt schon, dass Assemblerprogramme mit z.B. 100 kB wirklich eine vernünftiges System vorraussetzen. Assembler lässt einen halt auch wirklich alles durchgehen.
Superprofi schrieb: > Assemblerprogramme mit z.B. 100 kB Rein aus beruflichem Interesse: Wer schreibt 100kB große Assemblerprogramme für eine Plattform für die es seit langem bereits einige gute Compiler gibt? Was ist der praktische(!) (oder kommerzielle?) Anwendungsfall für so etwas, von Liebhaberei mal abgesehen? Das erste was mir bei sowas immer in den Sinn kommt ist jemand der ein 2m-Modell des Eiffelturms aus Streichhölzern baut. Das ist zwar äußerst beeindruckend, fällt aber IMHO mehr in die Kategorie Kunst als Architektur.
Superprofi schrieb: > Assembler lässt einen halt auch > wirklich alles durchgehen. Assembler läßt einen vor allem komplett im Regen stehen, was das strukturierte Programmieren betrifft. Man muß sich erstmal selber mühsam Regeln erstellen oder von anderen abgucken und sich auch diszipliniert daran halten. Man findet auch keinen, der mal den Code reviewen kann, was man daran noch verbessern könnte. Und vor allem wäre es mir schade um die verschwendete Arbeitszeit, wenn ich mal die CPU wechsele und dann die mühsam erstellten Asm-Libs wegschmeißen muß. Ich bin froh, daß ich schon auf dem 8051 mit C angefangen habe und daher viele Libs einfach auf den AVR portieren konnte.
Superprofi schrieb: > Assemblerprogramme mit z.B. 100 kB Wenn ich da mehr Erfahrung mit hätte, würde ich dich vielleicht loben. Aber so bleibt mir nur die ehrfürchtige Bewunderung.
Bernd K. schrieb: > Superprofi schrieb: >> Assemblerprogramme mit z.B. 100 kB > > Rein aus beruflichem Interesse: Wer schreibt 100kB große > Assemblerprogramme für eine Plattform für die es seit langem bereits > einige gute Compiler gibt? Was ist der praktische(!) (oder > kommerzielle?) Anwendungsfall für so etwas, von Liebhaberei mal > abgesehen? Das grösste, was wir mal geschrieben haben, war ein Displaytreiber mit allen möglichen Features. Dynamisch breite Fonts, objektbasierte Grafikfunktionen (so ein bissl wie eine 2D Game Engine. new Object Baum(x,y), alignment-optionen und das alles mit selbst entwickelter VRAM-Struktur. Sowas macht man einfach nicht in C, wenn man auf einem 8-Bitter noch eine vernünftige Framerate haben will. Achja und unser Taskmanager ist auch absolut genial. Der hat uns schon so viel Arbeit abgenommen. Multitasking auf einem 8-Bitter ist schon beeindruckend. C und ASM haben beides Vor- und Nachteile.
Wenn ich z.B. mal kurz ein Blinklicht haben will, was jede Sekunde blinkt, aber nichts blockiert, so brauche ich nur folgenden Code schreiben: blink: sbio VPORTA_OUT,Aled comebackafter 1000 cbio VPORTA_OUT,Aled gotoafter 1000 blink Und das in Assembler! Ich persönlich find das absolut geil :D
Superprofi schrieb: > > Das grösste, was wir mal geschrieben haben, war ein Displaytreiber mit > allen möglichen Features. Dynamisch breite Fonts, objektbasierte > Grafikfunktionen (so ein bissl wie eine 2D Game Engine. new Object > Baum(x,y), alignment-optionen und das alles mit selbst entwickelter > VRAM-Struktur. Sowas macht man einfach nicht in C, wenn man auf einem > 8-Bitter noch eine vernünftige Framerate haben will. > > Achja und unser Taskmanager ist auch absolut genial. Der hat uns schon > so viel Arbeit abgenommen. Multitasking auf einem 8-Bitter ist schon > beeindruckend. > > C und ASM haben beides Vor- und Nachteile. Aber was macht ihr, wenn ihr das mal portieren müsst? Auf einen ganz anderen µC? Neu anfangen?
Superprofi schrieb: > Und das in Assembler! Ich persönlich find das absolut geil :D Ja - Makro-King - und Du..schwätzer :-)
Superprofi schrieb: > Das grösste, was wir mal geschrieben haben, war ein Displaytreiber ... Es gehört zwar alles überhaupt nicht zum Thema, aber warum macht man so etwas auf einem 8-Bit-Prozessor? Sowas ähnliches haben wir vor 30 Jahren schon auf einem 8/16-Bit-Prozessor gemacht (80188, später H8), zunächst in Assembler, ab Mitte der 90er in C. Wo ist der Beweggrund, so etwas heute in 8 Bit und Assembler zu machen? Millionenstückzahlen und ein paar Cent sparen?
OssiFant schrieb: > Ja - Makro-King - und Du..schwätzer :-) Du solltest C-Hater mal anschreiben - so ganz ohne C-Date etc. - vielleicht passt ihr zusammen.
Arduino Fanboy D. schrieb: > Superprofi schrieb: >> Assemblerprogramme mit z.B. 100 kB > > Wenn ich da mehr Erfahrung mit hätte, würde ich dich vielleicht loben. > Aber so bleibt mir nur die ehrfürchtige Bewunderung. Ich habe aber mehr Erfahrung und daher weiss ich, dass das absoluter Blödsinn ist - niemand, aber auch niemand tut sich das an, es ist unlogisch und dumm. 100KB Assembler (ohne irgendwelche Tabellen u. ä.) ist so ein Ungetüm, da blickt keiner mehr durch. Wer will da einen ev. Fehler finden? Man kann Assembler in C-Programm einbinden (oder Pascal oder Basic), aber 100KB in Assembler schreibt doch kein normaler Mensch. Ich habe mal 20KB in Assembler geschrieben - einmal und nie wieder. Am Ende war das eine State machine mit Unmengen von Abfragen und Unterprogrammaufrufen. Ein paar Routinen in Assembler und alles andere in C wäre weitaus besser und übersichtlicher gewesen...
Moin, Dieter R. schrieb: > Wo ist der Beweggrund, so etwas heute in 8 Bit und Assembler zu machen? > Millionenstückzahlen und ein paar Cent sparen? Also ich persoenlich mach' sowas: a.) Weil's geht. b.) Weil ich's kann. c.) So ein bisschen als Ausgleich zum vernueftigen und braven Programmieren tagsueber. Gruss WK
Dergute W. schrieb: > c.) So ein bisschen als Ausgleich zum vernueftigen und braven > Programmieren tagsueber. Das Argument scheint mir, von allen hier im Thread genannten, das plausibelste zu sein. ;-)
Dergute W. schrieb: ... > Also ich persoenlich mach' sowas: > a.) Weil's geht. > b.) Weil ich's kann. > c.) So ein bisschen als Ausgleich zum vernueftigen und braven > Programmieren tagsueber. vor allem c.), aber auch: - wenn das letzte bisschen Strom gespart werden muss, ist es schick, wenn das Listfile von der Struktur her so wie das Quellfile aussieht - wenn man mit der Zulassungsbehörde/dem Kunden nicht über potentielle Compilerfehler reden will Was ich in diesem Thread nicht gefunden habe, aber vielleicht erbarmt sich der TO noch (ist vielleicht untergegangen): - welcher Assembler? - Codebeispiel plus Listfile - welcher Chip
Marcus H. schrieb: > ist es schick, > wenn das Listfile von der Struktur her so wie das Quellfile aussieht > - wenn man mit der Zulassungsbehörde/dem Kunden nicht über potentielle > Compilerfehler reden will Wie lange dauert es bis ein Beamter in einer Behörde 100kB Assemblercode gelesen, verstanden und im Kopf alle denkbaren Codepfade durchgegangen ist und auf Fehler abgeklopft hat die dem eigentlichen Autor entgangen sein könnten? Wäre ich der Beamte in der Zulassungsstelle würde ich den Antragsteller fragen ob er noch alle Tassen im Schrank hat mit sowas anzurücken. Wenn er darauf besteht veranschlage ich die voraussichtliche Zeitdauer der Prüfung auf 400 bis 500 Mannjahre, zahlbar im Voraus.
Marc V. schrieb: > Ich habe mal 20KB in Assembler geschrieben - einmal und nie wieder. Wir reden beide von AVR? Die Usability hängt ja stark vom Kern ab. PIC Assembler würde ich ehrlich gesagt nicht machen wollen. Das war dann auch "einmal und nie wieder".
Marcus H. schrieb: > Was ich in diesem Thread nicht gefunden habe, aber vielleicht erbarmt > sich der TO noch (ist vielleicht untergegangen): Das wurde eigentlich schon beantwortet. > - welcher Assembler? GAS, aber irrelevant, da auch ein BinDump gepostet wurde, also die Stufe NACH dem Assembler. > - Codebeispiel plus Listfile > - welcher Chip Beitrag "Re: XMEGA Hardware-Bug (Kritisch)"
Superprofi schrieb: > Das grösste, was wir mal geschrieben haben, war ein Displaytreiber mit > allen möglichen Features. Dynamisch breite Fonts, objektbasierte > Grafikfunktionen (so ein bissl wie eine 2D Game Engine. new Object > Baum(x,y), alignment-optionen und das alles mit selbst entwickelter > VRAM-Struktur. Sowas macht man einfach nicht in C, wenn man auf einem > 8-Bitter noch eine vernünftige Framerate haben will. > > Achja und unser Taskmanager ist auch absolut genial. Der hat uns schon > so viel Arbeit abgenommen. Multitasking auf einem 8-Bitter ist schon > beeindruckend. > > C und ASM haben beides Vor- und Nachteile. Ich wäre sehr am Namen deiner Firma interessiert, um diesen auf die Blacklist zu setzen. Sorry, im professionellen Umfeld, auch im Hobby, schreibt niemand mehr so komplexe Sachen in ASM.
Bimbo. schrieb: > Sorry, im professionellen Umfeld, auch im Hobby, > schreibt niemand mehr so komplexe Sachen in ASM. Was für Unsinn, ich bin hobbymäßiger Asm-Programmierer, programmiere ausschließlich in Assembler und ausschließlich XMEGAs und meine Programme komen schon an die 20 KB. Sicherlich sind solche Menschen wie ich in der Unterzahl, es gibt sie aber und man äußert sich eher ungern auf diesem Forum gerade in Bezug zu Assmebler/C. Ich kenne noch drei Typen die ebenfalls auschließlich Assembler programmieren.
AsmHobbyist schrieb: > Ich kenne noch drei > Typen die ebenfalls auschließlich Assembler programmieren. Und die tun mir alle leid :). In einer Hochsprache schreibst du schneller, fehlerfreier und übersichtlicher. Falsche Romantik ist hier total fehl am Platze. Willkommen im Jahr 2019. Assembler ist gut und es ist gut diesen gezielt einzusetzen - dort wo dieser benötigt wird, zur Optimierung. Linux ist in C geschrieben, freertos ist in C geschrieben - aus gutem Grund. Aber ganze Programme, 20-100kb groß ist so, als ob du auch die Bäume für den Hausbau im Garten züchtest und du deine Klinkersteine selber backst.
>deine Klinkersteine selber backst.
gut geraten, die mache ich aus Beton, Faserverstärkt, Form aus
OSB-Platten, geht ganz schnell.
Einst scheinst du nicht zu begreifen, ich kann Hochsprachen und kann
Klinkersteine kaufen, die Betonmischung selbst anzufertigen und im
Assembler zu Programmieren macht MIR Spaß. Shoppen und C nicht.
AsmHobbyist schrieb: > Einst scheinst du nicht zu begreifen, ich kann Hochsprachen und kann > Klinkersteine kaufen, die Betonmischung selbst anzufertigen und im > Assembler zu Programmieren macht MIR Spaß. Shoppen und C nicht. Und diese 20KB in Assembler machen genau was?
Marc V. schrieb: > AsmHobbyist schrieb: >> Einst scheinst du nicht zu begreifen, ich kann Hochsprachen und kann >> Klinkersteine kaufen, die Betonmischung selbst anzufertigen und im >> Assembler zu Programmieren macht MIR Spaß. Shoppen und C nicht. > > Und diese 20KB in Assembler machen genau was? Pipikram. Noch nicht mal ne Steinzeit-Textverarbeitung. Wordstar hatte 30 kByte und wurde angeblich in 4 Monaten geschrieben. Von einem (EINEM) Programmierer. Achso: ich bin ja nicht der Threadstarter und darf mir deshalb nur verhaltene Kritik erlauben, aber: 1. das gehört mittlerweile eher nicht mehr so richtig zum Thema und 2. wurde der Bug jetzt eigentlich bei Microchip gemeldet?
:
Bearbeitet durch User
Superprofi schrieb: > blink: > sbio VPORTA_OUT,Aled > comebackafter 1000 > cbio VPORTA_OUT,Aled > gotoafter 1000 blink > > Und das in Assembler! Ich persönlich find das absolut geil :D Was ist daran geil?? Oder habe nur ich die Ironie nicht verstanden?
@TO: Dein hier an den Tag gelegter Ton verbietet eigentlich jede Diskussion mit Dir. Das Thema war interessant genug, um mal draufzuschauen. Superprofi schrieb: > Marcus H. schrieb: >> Was ich in diesem Thread nicht gefunden habe, aber vielleicht erbarmt >> sich der TO noch (ist vielleicht untergegangen): > > Das wurde eigentlich schon beantwortet. > >> - welcher Assembler? > > GAS, aber irrelevant, da auch ein BinDump gepostet wurde, also die Stufe > NACH dem Assembler. Es gehört zum ordentlichen Arbeiten dazu, dass man zumindest die direkt beteiligten Werkzeuge nennt. > >> - Codebeispiel plus Listfile >> - welcher Chip > > Beitrag "Re: XMEGA Hardware-Bug (Kritisch)" In dem Gewühl hier ist es schwer, einen Überblick zu bekommen. Ich habe immer noch nicht gesehen, welcher Chip (Herstellerartikelnummer) zum Einsatz kommt. Ansonsten - nimm Dir das Datenblatt von Deinem Chip, schau Dir das Speichermodell an und rechne aus, wo der vom Assembler generierte Sprung den Programmzähler hinsetzen sollte. Wenn das immer noch nicht passt, gehst Du mit der Info an den Microsoft Support. Falls Du nicht in der Lage sein solltest, ein aussagekräftiges und höfliches Englisch zu schreiben, kannst Du Deine Anfrage hier posten, vielleicht übersetze ich sie Dir dann. Inhalt der Anfrage: das, worum ich Dich im letzten Post gebeten habe. Den Begriff "Hardware-Bug" würde ich vermeiden.
Superprofi schrieb: > Wenn ich z.B. mal kurz ein Blinklicht haben will, was jede Sekunde > blinkt, aber nichts blockiert, so brauche ich nur folgenden Code > schreiben: > > blink: > sbio VPORTA_OUT,Aled > comebackafter 1000 > cbio VPORTA_OUT,Aled > gotoafter 1000 blink Ein Blinklicht sieht bei mir so aus:
static void flash_green_led(void) { LED_GN = !LED_GN; } // ... schedule_add_cyclic(flash_green_led, TICKS(0.5)); |
Bernd K. schrieb: > Marcus H. schrieb: >> ist es schick, >> wenn das Listfile von der Struktur her so wie das Quellfile aussieht >> - wenn man mit der Zulassungsbehörde/dem Kunden nicht über potentielle >> Compilerfehler reden will > > Wie lange dauert es bis ein Beamter in einer Behörde 100kB Assemblercode > gelesen, verstanden und im Kopf alle denkbaren Codepfade durchgegangen > ist und auf Fehler abgeklopft hat die dem eigentlichen Autor entgangen > sein könnten? Ich hatte keinerlei Codegrößen und auch keine Architekturen genannt. Stell Dir einfach ein kleines Subsystem vor, welches Teil der Infrastruktur für den großen Prozessor nebendran ist. > Wäre ich der Beamte in der Zulassungsstelle würde ich den Antragsteller > fragen ob er noch alle Tassen im Schrank hat mit sowas anzurücken. Wenn > er darauf besteht veranschlage ich die voraussichtliche Zeitdauer der > Prüfung auf 400 bis 500 Mannjahre, zahlbar im Voraus. Ich habe bisher bei wirklich keiner benannten Stelle einen Betreuer gesehen, der auch nur den Anschein gemacht hätte, jemals so auftreten zu wollen, wie Du es hier beschreibst. Vielleicht, nur vielleicht, liegt es an der Art, wie man mit seinen Partnern umgeht? Macht es außerdem nicht Sinn, während der Entwicklung mit allen Beteiligten im Dialog zu stehen? Irgendwas zusammenzufrickeln und damit in die Zulassung zu gehen ist doch nicht zielführend. Bei Deiner ganzen Erfahrung im Bereich der Elektronikzertifizierung ist Dir noch nie Vorauskasse oder zumindest Anzahlung bei benannten Stellen untergekommen?
:
Bearbeitet durch User
Volker B. schrieb: > case 'y': USARTD0RomString(TstMsg); > _asm__ __volatile_ ("rjmp .+2"); > _asm__ __volatile_ ("nop"); > _asm__ __volatile_ ("nop"); > _asm__ __volatile_ ("rjmp .-8"); > USARTD0RomString(DoneMsg); > break; > > Auf dem E5 führt nur der zweite Teil Das ist ja schonmal deutlich aussagekräftiger. Also scheint das erste RJMP eine Adresse zu weit zu springen. Wäre noch interessant, ob andere Sprungarten auch betroffen sind, z.B. JMP oder BRTC.
Marcus H. schrieb: > - welcher Assembler? > - Codebeispiel plus Listfile > - welcher Chip Ja, das hätte ich mir im ersten Beitrag auch gewünscht. Codebeispiel ist wohl das hier:
hier: rjmp dort nop dort: rjmp hier neverever: ; hier kommt was, was nie ausgeführt werden dürfte ; aber auf XMEGA E doch ausgeführt wird |
Digikey findet mit "xmega e" 762 Resultate. Mouser nur eins: AVR XMEGA E5 Xplained Eval Kit (ATXMEGAE5-XPLD) Vielleicht ist das gemeint, aber wer weiß das schon, außer dem TO (thread opener).
Nun drehen wir uns hübsch im Kreise. Darf ich daran erinnern: Autor: Volker B. (Firma: L-E-A) (vobs) Datum: 01.06.2019 10:47 Hallo, ich habe Deinen Code nun aus einem ATxmega32E5 und einem ATxmega32A4U getestet, ... Auf dem E5 führt nur der zweite Teil, also das Kommando 'y' in eine Endlosschleife, auf dem A4U beide. Grüßle Volker Für eine höflich formulierte Bug-Meldung dürfte das hinreichen. das sollte allerdings jemand tun, der in seiner Arbeit direkt davon betroffen ist, es könnten ja weitere Rückfragen kommen. Auf mich trifft das nicht zu.
Dieter R. schrieb: ... > ich habe Deinen Code nun aus einem ATxmega32E5 und einem ATxmega32A4U > getestet, ... > > Auf dem E5 führt nur der zweite Teil, also das Kommando 'y' in eine > Endlosschleife, auf dem A4U beide. ... OK, Frage: - angenommen der Code startet an Adresse 0 und der komplette restliche Programmspeicher ist mit nop gefüllt - nun nimmt man seinen ICD, führt einen Reset aus und geht im Einzelschrittbetrieb durch den Code Wie ist der tatsächliche Codefluss? Wie passt das mit dem Datenblatt (Speicherstruktur, Befehlsstruktur, Interruptstatus, etc.) zusammen? Diese Information, zusätzlich zur Nennung der Randbedingungen, wäre der Ausgangspunkt für so einen Thread gewesen.
Marcus H. schrieb: > führt einen Reset aus und geht im Einzelschrittbetrieb durch den Code Dabei ist keinesfalls garantiert, dass du das gleiche Verhalten erreichst wie im genannten Bug. Schließlich muss ja bei Einzelschritt die CPU jedesmal mit einem (automatischen) Breakpoint angehalten werden. An welcher Stelle das Muster im Speicher steht, ist bei den relativen Sprüngen eines AVRs übrigens völlig irrelevant; RJMP hat einen erreichbaren PC-Bereich, der stets vom aktuellen PC ausgehend gerechnet wird (genauer: vom PC des nächsten Befehls, denn der aktuelle wurde ja zu diesem Zeitpunkt bereits decodiert). Damit ist ein RJMP .+2 oder RJMP .-6 immer im erreichbaren Bereich. Es ist natürlich interessant, dass Atmel es geschafft hat, derart spät in der Evolution dieses CPU-Kerns noch einen derartigen Bug zu platzieren … man hätte nicht unbedingt erwartet, dass für die Weiterentwicklung der ATxmegas hin zum Xmega E nochmal der Kern modifiziert worden wäre.
Jörg W. schrieb: > Marcus H. schrieb: >> führt einen Reset aus und geht im Einzelschrittbetrieb durch den Code > > Dabei ist keinesfalls garantiert, dass du das gleiche Verhalten > erreichst wie im genannten Bug. Schließlich muss ja bei Einzelschritt > die CPU jedesmal mit einem (automatischen) Breakpoint angehalten werden. Ganz klar. Aber auch die Info, ob das Verhalten bei Single-Step noch auftritt wäre interessant. > > An welcher Stelle das Muster im Speicher steht, ist bei den relativen > Sprüngen eines AVRs übrigens völlig irrelevant; RJMP hat einen > erreichbaren PC-Bereich, der stets vom aktuellen PC ausgehend gerechnet > wird (genauer: vom PC des nächsten Befehls, denn der aktuelle wurde ja > zu diesem Zeitpunkt bereits decodiert). Damit ist ein RJMP .+2 oder RJMP > .-6 immer im erreichbaren Bereich. Die nop sind dafür da, dass der ICD einen legalen Befehl findet, falls der Code in die Pampa springt. Ich bin mir immer noch nicht sicher, wo der gezeigte Code den SP tatsächlich hinsetzt und wo er laut Herstellerangaben hingehört. Wenn alle Info zusammengestellt ist, darf das gerne jemand ausrechnen. Du weißt ja, dass ich bei den AVRs schon seit dem 1200er dabei bin, und das Ausnutzen von Wrapping ist natürlich nichts neues. Xmegas kenne ich nicht, ich bin hier nur wegen des reißerischen Threadnamens reingestolpert. Ein Verdacht den ich hatte basiert darauf, dass wir eine Speicherstruktur haben, bei der das Wrapping nicht so funktioniert, wie es beim Assembler eingestellt ist. > Es ist natürlich interessant, dass Atmel es geschafft hat, derart spät > in der Evolution dieses CPU-Kerns noch einen derartigen Bug zu > platzieren … man hätte nicht unbedingt erwartet, dass für die > Weiterentwicklung der ATxmegas hin zum Xmega E nochmal der Kern > modifiziert worden wäre. Microchip hat einiges in Bewegung gebracht. Bei den AVRs gibt es neue Tinys (z.B. ATtiny414), deren CPU und Speichermodell neu ist. Im Gegenzug sind die Dinger aber billig und energieeffizient. Ich habe Anfang März zwei Medizinprodukte durch die Zulassung geschoben, bei denen solche Chips, mit kleinen Assemblerprogrammen versehen, sich u.a. um das Energiemanagement kümmern. Mein Job war die Hardwareentwicklung der Gesamtsysteme, die Programmierung der ATtinys, sowie Unterstützung bei der Treiberentwicklung für den großen Mehrkerncontroller, der natürlich Multitasking macht und in C Programmiert wird.
Marcus H. schrieb: > Du weißt ja, dass ich bei den AVRs schon seit dem 1200er dabei bin, und > das Ausnutzen von Wrapping ist natürlich nichts neues. Xmegas kenne ich > nicht, ich bin hier nur wegen des reißerischen Threadnamens > reingestolpert. [troll-modus] Muss man nicht kennen ... XMEGAs haben keine Vorteile gegenüber Cortex-M[/troll-modus]
Mampf F. schrieb: > XMEGAs haben keine Vorteile gegenüber Cortex-M Für einen ausgemachten Assemblerprogrammierer schon: er muss seinen Code nicht neu schreiben. :-))
Mampf F. schrieb: > Marcus H. schrieb: >> Du weißt ja, dass ich bei den AVRs schon seit dem 1200er dabei bin, und >> das Ausnutzen von Wrapping ist natürlich nichts neues. Xmegas kenne ich >> nicht, ich bin hier nur wegen des reißerischen Threadnamens >> reingestolpert. > [troll-modus] Muss man nicht kennen ... XMEGAs haben keine Vorteile > gegenüber Cortex-M[/troll-modus] Ah, "kennen" heißt in diesem Kontext: ich hatte noch nicht den Bedarf für diese Familie Hardware/Firmware-Entwicklung zu betreiben. Als die Teile auf den Markt kamen, war ich mit den STM32 schon fit genug, dass AVR und deren Derivate in meinem Umfeld nur noch für sehr wenige Anwendungen Sinn gemacht haben. Dann aber bevorzugt die Tinys mit sehr kompakten Maschinenprogrammen. Letzten Herbst hat ein Neukunde eine Entwicklung bei mir bestellt, weil er beim vorhandenen Design mit XMEGA128A1 an die Grenzen gekommen war und er eine saubere Hardware- und Firmwareplattform für STM32F4 gebraucht hat. ;)
:
Bearbeitet durch User
Jörg W. schrieb: > Mampf F. schrieb: >> XMEGAs haben keine Vorteile gegenüber Cortex-M > > Für einen ausgemachten Assemblerprogrammierer schon: er muss seinen Code > nicht neu schreiben. :-)) Neugierdehalber: Hast Du an Compilerentwicklungen für die neueren AVR-Derivate mitgemacht?
Mampf F. schrieb: > [troll-modus] Muss man nicht kennen ... XMEGAs haben keine Vorteile > gegenüber Cortex-M[/troll-modus] Sad but true.
Marcus H. schrieb: > Hast Du an Compilerentwicklungen für die neueren AVR-Derivate > mitgemacht? Nein, Compiler ist nicht mein Ding. Johann (Georg Lay) ist da der Experte, zuvor hatte noch Andrey Chernov einiges gemacht, auch einige andere davor, und beim Xmega hatte auch Atmel selbst seine Finger im Spiel, soweit ich mich erinnere.
Testweise sollte man mal vor der ersten Anweisung noch ein paar NOPs einfügen und gern auch zwischen den beiden Sprüngen und schauen, ob sich das erwartete Verhalten einstellt.
Georg schrieb: > Testweise sollte man mal vor der ersten Anweisung noch ein paar NOPs > einfügen und gern auch zwischen den beiden Sprüngen und schauen, ob sich > das erwartete Verhalten einstellt. Nö. Bug ist Bug und sollte berichtet werden bei Microchip. Analyse des Bugs ist deren Aufgabe. Ist ja nicht so, dass so eine CPU zufällig irgendwas tut, sondern wenn sie falsch arbeitet, liegt dem sehr wahrscheinlich ein fehlerhafter Verilog-Code zugrunde. Anhand des tatsächlichen Codes können sie dann auch sicher sagen, welchen Workaround sie empfehlen.
Jörg W. schrieb: > Nö. Bug ist Bug und sollte berichtet werden bei Microchip. Mir kommt dieser Bug irgendwie bekannt vor ... Ich hätte gemeint, dass es so einen rjmp-Bug schon mal in den allerersten AVRs gab ... Muss ich mal danach suchen - vlt irre ich mich aber auch.
Ah hatte ich falsch in Erinnerung ... War damals auf dem ATMEGA103: > Skip Instruction with Interrupts > A skip instruction (SBRS, SBRC, SBIS, SBIC, CPSE) > that skips a two-word instruction needs three clock > cycles. If an interrupt occurs during the first or second > clock cycle of this skip instruction, the return address > will not be stored correctly on the stack.
Ich hab den Bug auf Microchip gemeldet - mal schauen, was raus kommt.
Jörg W. schrieb: > Es ist natürlich interessant, dass Atmel es geschafft hat, derart spät > in der Evolution dieses CPU-Kerns noch einen derartigen Bug zu > platzieren Vielleicht haben sie nen anderen Silicon-Bug gefixt, von dem wir (noch) nix wissen, und diesen dabei eingebaut :-P Interessanterweise verfügt der ATxmega32E5 nicht über die Read-Modify-Write-Instruktionen (LAS, LAT, LAC, XCH), während der nicht betroffene ATxmega32A4U RMW untestützt. Allerdings ist noch nicht bekannt, welche Revisions betroffen sind und zu welcher Revision der getestete A4U gehört. Marcus H. schrieb: > Compilerentwicklungen Findet momentan praktisch nicht statt, so dass auch trivial zu fixende Bugs wie PR86040 unbearbeitet bleiben. Marcus H. schrieb: > Bei den AVRs gibt es neue Tinys (z.B. ATtiny414), deren CPU [...] Ist ne normale Xmega CPU. Ob Atmochip nen µC "Tiny" oder "Mega" nennt hängt nicht am Instruktionssatz oder Anzahl GPRs, sondern wieviel Beinchen das Ding hat. > [...] und Speichermodell neu ist. Gefühlt 15 Jahre zu spät. Bereits die Reduced Tiny hatten ein lineares Speichermodell (z.B. ATtiny40, deren ISA unterstützt noch nichtmal LPM). Linearisierung ist also ohne Nebeneffekte (wie z.B. langsamere Instruktionen bzw. Speicherzugriff) machbar. Mampf F. schrieb: > Skip Instruction with Interrupts > A skip instruction (SBRS, SBRC, SBIS, SBIC, CPSE) > that skips a two-word instruction needs three clock > cycles. If an interrupt occurs during the first or second > clock cycle of this skip instruction, the return address > will not be stored correctly on the stack. Den kann der Compiler einfach umgehen, z.B:
char i; void store (char c) { if (c) i = 0; } |
ATmega128
store: cpse r24,__zero_reg__ sts i,__zero_reg__ ret |
ATmega103
store: tst r24 breq .L2 sts i,__zero_reg__ .L2: ret |
oder in der libgcc:
#ifdef __AVR_ERRATA_SKIP_JMP_CALL__ tst SS brpl 4f #else sbrc SS, 7 #endif XCALL __negdi2 4: |
Auf Assembler-Ebene gibt's ne Warnung bei so einem Konstrukt:
__asm ("sbrc 0,0 $ lds 0,0");
Assembler messages:
Warning: skipping two-word instruction
|
Den neuen Bug kann man auf Compilerebene jedoch nicht umgehen; schon deshalb weil ein RJMP-NOP-RJMP mit C/C++ nicht erzeugbar ist; wobei wir hier die Antwort abwarten müssen, welcher Sequenzen genau betroffen sind. Marcus H. schrieb: > Ein Verdacht den ich hatte basiert darauf, dass wir eine > Speicherstruktur haben, bei der das Wrapping nicht so funktioniert, > wie es beim Assembler eingestellt ist. Ich wette auf die Pipeline.
:
Bearbeitet durch User
Johann L. schrieb: > Ob Atmochip nen µC "Tiny" oder "Mega" nennt hängt nicht am > Instruktionssatz oder Anzahl GPRs, sondern wieviel Beinchen das Ding > hat. Nicht unbedingt, aber aktuell offenbar. Von ATmega48/88 wurden später noch Abrüstversionen gebaut, die man ATtiny48/88 nannte. Gleiches Pinout, aber reduzierter Core (z.B. kein MUL), damit kleinerer Die. Führte dazu, dass man den ATtiny48 alternativ in einem etwas kleineren Gehäuse anbieten konnte (wimre. 4x4 QFN statt 5x5). > Ich wette auf die Pipeline. So viel Pipeline hat ein AVR ja eigentlich gar nicht … oder haben sie beim ATxmegaE da was eingeführt? Das würde es natürlich erklären.
Jörg W. schrieb: > Johann L. schrieb: >> Ich wette auf die Pipeline. > > So viel Pipeline hat ein AVR ja eigentlich gar nicht Soweit ich weiß eine 2-stufige Pipeline. Natürlich nicht für den Anwender sichtbar (die einzige Instruktion, für die das ISA-Manual keine feste Zeit angibt, ist SPM. Und das hat bestimmt nix mit der Pipeline zu tun). > oder haben sie beim ATxmegaE da was eingeführt? Das würde es > natürlich erklären. Außer auf Core-Ebene, also was für Compiler oder Simulator relevant ist, hab ich mich mit den Dingern nicht auseinandergesetzt. Und eingesetzt auch nicht. Dokumente über die Interna sind mir keine bekannt. Einige Timings haben sich zwar geändert (CBI, SBI, [[E]I]CALL, LDS, PUSH, SBIC/S) sind innerhalb der Xmega-Familie aber gleich, zumindest gemäß ISA-Manual.
Ah, der Thread zieht ja langsam richtig Prominenz an. ;) Johann L. schrieb: > Marcus H. schrieb: >> Bei den AVRs gibt es neue Tinys (z.B. ATtiny414), deren CPU [...] >> [...] und Speichermodell neu ist. > > Ist ne normale Xmega CPU. Ob Atmochip nen µC "Tiny" oder "Mega" nennt > hängt nicht am Instruktionssatz oder Anzahl GPRs, sondern wieviel > Beinchen das Ding hat. Jörg ist hierauf ja schon eingegangen. Ich habe gefühlt drei unterschiedliche Generationen AVRs im Kopf: - die ersten AT90Sxxxx, die noch so klein waren, dass die meisten Speicherstellen ohne Handstände zu erreichen waren. Einzige Ausnahme war da der alte 128er - die Megas, bei denen soviel Peripherie dazugekommen war, dass man deren Register größtenteils indirekt addressieren musste - die neueren ATtiny / AVR 1 (e.g. ATtiny414), deren recht leistungsfähige Peripherie praktisch komplett indirekt addressiert werden muss. Das sind aus meiner Sicht derzeit die interessantesten Chips, weil die vom Energiebedarf und Preis einen Bereich unterhalb der STM32x0 abdecken > Gefühlt 15 Jahre zu spät. Bereits die Reduced Tiny hatten ein lineares > Speichermodell (z.B. ATtiny40, deren ISA unterstützt noch nichtmal LPM). > Linearisierung ist also ohne Nebeneffekte (wie z.B. langsamere > Instruktionen bzw. Speicherzugriff) machbar. seufz wir werden alle nicht jünger > Marcus H. schrieb: >> Ein Verdacht den ich hatte basiert darauf, dass wir eine >> Speicherstruktur haben, bei der das Wrapping nicht so funktioniert, >> wie es beim Assembler eingestellt ist. > > Ich wette auf die Pipeline. Yep, auf die Wette werde ich zum jetzigen Zeitpunkt nicht eingehen. ;) Da der TO sich weder in Form noch Inhalt an die Netiquette hält, hat es viel zu lange gedauert, bis man seine Behauptung ernst nehmen konnte. Falls sich seine Behauptung bestätigen sollte, wäre das sehr schade. Aber auch der Präsentationstil ist wichtig. Nachdem nun endlich hinreichend Information beinander sind, habe ich mal AVR-Studio 7, sowie den AVR Befehlssatz (inkl. Opcode-Liste) aufgemacht und den Code eingegeben. Wird für ATXMEGA32E5 und ATtiny414 in die selben HEX-Daten übersetzt, wie vom TO gezeigt. Damit sollte das Thema Assemblerfehler vom Tisch sein. Bei Singlestepping verhält sich der Code im Simulator wie erwartet (Endlosschleife). Mangels Hardware kann ich das Verhalten am lebenden Objekt nicht überprüfen. start: l1: 000000 c001 rjmp l2 000001 0000 nop l2: 000002 cffd rjmp l1 000003 0000 nop 000004 0000 nop 000005 cffa rjmp start Falls jemand sich die Mühe machen könnte, das Beispiel an einem echten ATXMEGA32E5 in einer zulässigen Hardwareumgebung im Normalbetrieb und im Debugbetrieb (Singlestep) zu überprüfen, dann wüsste man im Vorfeld, in welche Richtung die Antwort von Microchip gehen sollte. Referenz: https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_RJMP.html
Johann L. schrieb: > Jörg W. schrieb: >> Johann L. schrieb: >>> Ich wette auf die Pipeline. >> >> So viel Pipeline hat ein AVR ja eigentlich gar nicht > > Soweit ich weiß eine 2-stufige Pipeline. Natürlich nicht für den > Anwender sichtbar (die einzige Instruktion, für die das ISA-Manual keine > feste Zeit angibt, ist SPM. Und das hat bestimmt nix mit der Pipeline > zu tun). Jedes AVR Datenblatt hat doch ein Kapitel "Functional Description" - da sieht man doch wie das Timing ist und warum Jumps mindestens zwei Takte brauchen.
:
Bearbeitet durch User
Marcus H. schrieb: > Damit sollte das Thema Assemblerfehler vom Tisch sein. Das war nie ein Thema, denn die generierten Befehle hatte der TO ja mit angegeben. Sein Stil mag nicht OK sein, aber dass man sich anschließend daran hochzog, dass er Unix-Assembler-mäßige f/b-Labels benutzt hat (die hat ja keineswegs der GAS erst erfunden, die gab es schon Jahre davor auch bei x86/Unix), war ein völlig unsinniger Nebenschauplatz.
Jörg W. schrieb: > Marcus H. schrieb: >> Damit sollte das Thema Assemblerfehler vom Tisch sein. > > Das war nie ein Thema, denn die generierten Befehle hatte der TO ja mit > angegeben. Der Ausschnitt aus dem Listfile kam im 52. Post. Bei dieser Art Fehlerbeschreibung wäre es professionell, den Hexcode und die Infrastruktur im Eingangspost zu nennen. > Sein Stil mag nicht OK sein, aber dass man sich anschließend > daran hochzog, dass er Unix-Assembler-mäßige f/b-Labels benutzt hat (die > hat ja keineswegs der GAS erst erfunden, die gab es schon Jahre davor > auch bei x86/Unix), war ein völlig unsinniger Nebenschauplatz. Die f/b Labels werden AFAIK von Atmel Studio 7 bis einschließlich V7.0 nicht unterstützt. Für den Nichteingeweihten lenkt das vom Thema ab. Noch gibt es Windows-Benutzer hier im Forum. Insgesamt ein wichtiger Thread mit vollkommen unnötig verplemperter Zeit durch die Präsentationsform. Man versetze sich in die Lage eines Supportmitarbeiters, der sowas bearbeiten muss.
:
Bearbeitet durch User
Marcus H. schrieb: > Der Ausschnitt aus dem Listfile kam im 52. Post. Der generierte Code steht im ersten, wenn auch fälschlich als "compilierter" bezeichnet, aber mit wenig Phantasie kann man sich das zusammenreimen. > Die f/b Labels werden AFAIK von Atmel Studio 7 bis einschließlich V7.0 > nicht unterstützt. Atmel Studio ist ein Editor bzw. eine IDE. Dass der Atmel-Assembler das nicht unterstützt, ist richtig. Der war und ist seit Jahrzehnten halt sehr primitiv gehalten. Bspw. kann hat er keinen Linker und arbeitet rein absolut, ohne verschieblichen Objektcode, den Assembler schon vor vielen Jahrzehnten beherrscht haben. Auch in Atmel Studio kann man den GNU Assembler benutzen, denn die GCC-Toolchain wird ohnehin typischerweise mit installiert. Zumindest darf man als Assemblerprogrammierer ruhig auch mal soweit über den Tellerrand blicken, dass man bei den genannten Labels nicht gleich in Zweifel stellt, dass sie funktionieren oder festlegt, sie seien unsinnig (zweites Posting). Im dritten Posting war zumindest dann die korrekte Vermutung geäußert, wie sie denn funktionieren, aber trotzdem wird danach weiterhin auf dem TO herumgehackt, weil er dieses Feature seines Assemblers benutzt und auch sonst nicht so schön schreibt, wie manch einer sich das wünscht. Dass es sich tatsächlich um einen Siliziumbug handelt, will lange Zeit gar keiner wahr haben …
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Sein Stil mag nicht OK sein, aber dass man sich anschließend > daran hochzog, dass er Unix-Assembler-mäßige f/b-Labels benutzt hat (die > hat ja keineswegs der GAS erst erfunden, die gab es schon Jahre davor > auch bei x86/Unix), war ein völlig unsinniger Nebenschauplatz. Korrekt, das sehe ich auch so. Ich kannte das noch nicht, aber das ist mein Problem. Sehe ich ein.
:
Bearbeitet durch User
Danke, Stefan. Mal sehen, was Atmicrochip dazu zu sagen hat … wird dort typischerweise auch ein paar Tage dauern, bis der Frontline-Supporter akzeptiert, dass das kein AZB-Fehler*) ist, sondern ein Bug, den er weitermelden muss. *) Anwender Zu Blöd
Nee, im ersten Beitrag steht nur rjmp 1f nop 1: rjmp 2b Kompiliert zu: rjmp .+2 nop rjmp .-6 Unter kompiliert zu kann man sich jetzt alles vorstellen, auch allen Unsinn. Ein Listing sieht definitiv anders aus. Und danach kam auf Rückfragen erstmal garnichts und dann Beschimpfungen. Ganz schlechter Stil. Aber nun wissen wir es ja und Microchip ist gefragt.
Drei, unterwegs schrieb: > Unter kompiliert zu kann man sich jetzt alles vorstellen, auch allen > Unsinn. Man kann aber auch seinen Denkkasten einschalten, dann kommt man ziemlich zielsicher im genannten Kontext zu dem Schluss, dass es sich um den generierten und disassemblierten Maschinencode handelt.
Oh, wie freundlich mal wieder. Es ist eben gerade kein Maschinencode, sondern nur Memonics. Daher ja der anfängliche Verdacht, dass es sich um einen Assemblerfehler handelte. Wobei hinzukam, dass der TO zwar sehr großspurig auftrat, in den Begriffen aber nicht besonders sattelfest erschien.
Ich persönlich fand es absolut unprofessionell, dass man auf Details rumgehackt hat, die überhaupt nicht Thema waren. Natürlich hätte ich es noch viel schöner aufbereiten können, mit Powerpoint Präsentation etc. Aber warum sollte ich mir bitte die Arbeit machen? Letztendlich habe ich hier aus reiner Gefälligkeit gegenüber anderen xmega Programmierern ein Problem geschildert und direkt ein Work-Around geliefert. Ich habe weder nach Dank noch nach Belohnung oder Anerkennung verlangt. Statt dessen wurde ich von allen Seiten nieder gemacht und ich "durfte" hier wesentlich mehr Zeit reinstecken, als ich eigentlich geplant hatte. Ich habe es mir eigentlich so vorgestellt, dass mal einer oder zwei Leute sich einen xmega schnappen und das kurz nachstellen. Es ist ja auch im Eigeninteresse, sowas zu verifizieren. Wenn der Fehler NICHT aufgetreten wäre, hätte man darüber sachlich diskutieren können. Das war auch der Grund, warum ich nur "xmega E" gesagt habe, weil meiner Meinung nach weder Package noch Ausbau eine Rolle spielen, da es den Core betrifft. Es sollte also heissen, dass sich, bei Interesse, jemand einfach irgendeinen xmega E schnappen soll um es auszuprobieren. Es kann natürlich sein, dass die Bastelzeiten vorbei sind und keiner hier einen xmega rumfliegen hat und es deshalb eine Zumutung ist, so etwas vorrauszusetzen. Dann habe ich das Forum falsch eingeschätzt und es tut mir leid. Ich habe mir auch meine Beiträge nochmals durchgelesen und habe ausschliesslich auf Beleidigungen beleidigend geantwortet. Tut mir leid, aber ich bin auch nur ein Mensch.
Superprofi schrieb: > Es kann natürlich sein, dass die Bastelzeiten vorbei sind und keiner > hier einen xmega rumfliegen hat Die xmega dürften in der Tat erheblich seltener verbreitet sein, als die klassischen AVRs. Bei mir sind die Ausschlußkriterien, daß ich gerne 5V verwende und den CAN-Bus.
Superprofi schrieb: > Es kann natürlich sein, dass die Bastelzeiten vorbei sind und keiner > hier einen xmega rumfliegen hat Xmegas habe ich zwar, aber ein Xmega E ist meiner Erinnerung nach nicht dabei. Sonst hätte ich es auch gern selbst mal getestet.
Ich habe leider nur einen Xmega A und ein paar Xmega D vorrätig.
:
Bearbeitet durch User
Ich habe den Bug hier schonmal vor einem Jahr gepostet. Damals war das Interesse aber auch nicht grad berauschend: Beitrag "Sehr komisches AVR Assembler Problem. Nur drei Anweisungen!"
Superprofi schrieb: > Ich habe den Bug hier schonmal vor einem Jahr gepostet. Das ist ja interessant. Wie ist denn damals der Kontakt mit dem Hersteller verlaufen?
Ich habe damals keinen Kontakt mit dem Hersteller gesucht, da ich damals davon ausgegangen bin, dass der Fehler irgendwo bei mir liegt.
Superprofi schrieb: > Ich habe damals keinen Kontakt mit dem Hersteller gesucht, da ich > damals > davon ausgegangen bin, dass der Fehler irgendwo bei mir liegt. Und du hast ein Jahr gebraucht, um herauszufinden, dass der Fehler nicht bei dir liegt?
Mampf F. schrieb: > Und du hast ein Jahr gebraucht, um herauszufinden, dass der Fehler nicht > bei dir liegt? ... oder Deinem Assembler ...
Ich muss hinzufügen: Mit AVRASM geeigneten Labels (nicht numerisch am Anfang) hat zumindest der Simulator keine Probleme. Aus der E-Reihe habe ich leider keinen ATXMega (warum auch?) und kann es hardware-seitig nicht nachstellen.
Hallo, Ich hab folgendes mal auf einem XMEGA32e5 getestet:
.include <ATxmega32e5def.inc> ; Replace with your application code ldi r16, 0x01 sts PORTD_DIRSET, r16 start: inc r16 anfang: rjmp weiter nop weiter: rjmp anfang ldi r16, 0x01 sts PORTD_OUTTGL, r16 rjmp start |
Was zu folgenden compiliert :
00008000 LDI R16,0x01 Load immediate 00008001 STS 0x0661,R16 Store direct to data space 00008003 INC R16 Increment 00008004 RJMP PC+0x0002 Relative jump 00008005 NOP No operation 00008006 RJMP PC-0x0002 Relative jump 00008007 LDI R16,0x01 Load immediate 00008008 STS 0x0667,R16 Store direct to data space 0000800A RJMP PC-0x0007 Relative jump |
Den Block am Ende
ldi r16, 0x01 sts PORTD_OUTTGL, r16 rjmp start |
wird genau einmal ausgeführt und dann ist der XMEGA in der Endlosschleife. Egal wie viele nops ich einfüge es wird einmal ausgeführt. Wenn ich die Entlosschleife entferne sieht man das togglen gut am Oszi. Gruß JackFrost
>00008006 RJMP PC-0x0002 Relative jump Ich kenne die Arbeitsweise deines Assemblers nicht, aber bei mir steht da > 4: fd cf rjmp .-6 Sieht für mich nach einem anderen Sprungziel aus.
Ich muss hinzufügen: Mit AVRASM geeigneten Labels (nicht numerisch am Anfang) hat zumindest der Simulator keine Probleme. Aus der E-Reihe habe ich leider keinen ATXMega (warum auch?) und kann es hardware-seitig nicht nachstellen. Bastian W. schrieb: > .include <ATxmega32e5def.inc> > ; Replace with your application code > ldi r16, 0x01 > sts PORTD_DIRSET, r16 > start: > inc r16 > anfang: > rjmp weiter > nop > weiter: > rjmp anfang > ldi r16, 0x01 > sts PORTD_OUTTGL, r16 > rjmp start Warum springst Du zu "start" zurück? Wenn Du nur toggeln willst ist das nicht erforderlich.
OssiFant schrieb: > Warum springst Du zu "start" zurück? Wenn Du nur toggeln willst ist das > nicht erforderlich. Der Sprung zu Start ist nur drinnen wenn der Bug vorhanden da ist müsste der uC die Endlosschleife
anfang: rjmp weiter nop weiter: rjmp anfang |
ingnorieren und dann sollte der Pin toggeln. Es wird aber nur einmal ausgeführt und dann bleibt er in dem Block da oben. Eigentlich dürfte er da nie hinkommen und der Pin müsste immer low sein. Auch mit
anfang: rjmp weiter nop weiter: rjmp anfang nop nop nop nop nop nop |
Wird das toggle einmal ausgeführt und dann nie wieder. Superprofi schrieb: >>00008006 RJMP PC-0x0002 Relative jump > > Ich kenne die Arbeitsweise deines Assemblers nicht, aber bei mir steht > da > >> 4: fd cf rjmp .-6 > > Sieht für mich nach einem anderen Sprungziel aus. Es ist der AVR Assembler aus dem Atmelstudio 7. Gruß JackFrost
Superprofi schrieb: > Sieht für mich nach einem anderen Sprungziel aus. Für mich auch. Jetzt bräuchte man wohl wirklich noch die Opcodes dazu.
Bastian W. schrieb: > Ich hab folgendes mal auf einem XMEGA32e5 getestet: > > 00008000 LDI R16,0x01 Load immediate Der Code beginnt bei 8000? > wird genau einmal ausgeführt und dann ist der XMEGA in der > Endlosschleife. Interessant, Hast du Revision / DateCode des ATxmega32E5? OssiFant schrieb: > der Simulator keine Probleme. Das wundert dich jetzt nicht wirklich.
Ich hab das Hexfile mit dem ODA dissasembliert.
.data:00000000 01 e0 ldi r16, 0x01 ; 1 .data:00000002 00 93 61 06 sts 0x0661, r16 .data:00000006 03 95 inc r16 .data:00000008 01 c0 rjmp .+2 ; 0x0000000c .data:0000000a 00 00 nop .data:0000000c fd cf rjmp .-6 ; 0x00000008 .data:0000000e 01 e0 ldi r16, 0x01 ; 1 .data:00000010 00 93 67 06 sts 0x0667, r16 .data:00000014 f8 cf rjmp .-16 ; 0x00000006 |
Und als Intelhex
:020000020000FC :1000000001E000936106039501C00000FDCF01E00F :0600100000936706F8CF23 :00000001FF |
Gruß JackFrost
:
Bearbeitet durch User
Johann L. schrieb: > Interessant, Hast du Revision / DateCode des ATxmega32E5? Das ist komisch, weil im Hex ist as ja 0x0000. Die Fuse für den Bootloader war auf Bootsektion gestellt, dann zeigt das Atmel Studio 7 als Start 0x8000 im Disassmbliertem Code an. Wenn die Fuse auf App section steht 0x0000. Es ändert sich aber nichts am Verhalten Gruß JackFrost
:
Bearbeitet durch User
Wenn ich das laden von 0x01 in R16 vor den rjmp ziehe dann bleibt der XMega direkt in der Endlosschleife
.include <ATxmega32e5def.inc> ; Replace with your application code ldi r16, 0x01 sts PORTD_DIRSET, r16 start: inc r16 anfang: rjmp weiter nop weiter: ldi r16, 0x01 rjmp anfang // ldi r16, 0x01 sts PORTD_OUTTGL, r16 rjmp start |
Gruß JackFrost
Johann L. schrieb: >> der Simulator keine Probleme. > > Das wundert dich jetzt nicht wirklich. Wobei es zumindest auch mal einen Simulator gab, der tatsächlich direkt vom Verilog-Code aus einen taktzyklenkompatiblen C-Code für die Simulation generiert hat. Ein solcher hätte natürlich den Verilog-Code bugkompatibel simulieren sollen. Kann aber sein, dass der bei Xmega nicht (mehr) verwendet worden ist, sei es aus Lizenzgründen oder was auch immer.
Hmmm kannst du mal bitte angehängtes binfile auf deinen xmega flashen? Bei mir geht da die LED an. Geflasht via: avrdude -p atxmega8e5 -c avrispmkii -eU flash:w:main.bin:r Source: ;HW Bug: Diese Endlosschleife ist nicht endlos. 2: rjmp 1f nop 1: rjmp 2b ;D0 auf HIGH setzen ldi r24,0x01 sts PORTD_DIR,r24 sts PORTD_OUTSET,r24 ;Gewollte Endlosschleife 1: rjmp 1b
Superprofi schrieb: > Hmmm kannst du mal bitte angehängtes binfile auf deinen xmega flashen? > Bei mir geht da die LED an. Werde ich morgen machen. Bei mir geht die LED bei folgendem nicht an :
.include <ATxmega32e5def.inc> ; Replace with your application code ldi r16, 0x01 sts PORTD_DIRSET, r16 start: inc r16 anfang: rjmp weiter nop weiter: ldi r16, 0x01 rjmp anfang // ldi r16, 0x01 sts PORTD_OUTTGL, r16 rjmp start |
Bei dem geht sie an, toggelt aber nicht
.include <ATxmega32e5def.inc> ; Replace with your application code ldi r16, 0x01 sts PORTD_DIRSET, r16 start: inc r16 anfang: rjmp weiter nop weiter: rjmp anfang ldi r16, 0x01 sts PORTD_OUTTGL, r16 rjmp start |
Und hier toggelt sie , was sie auch soll
.include <ATxmega32e5def.inc> ; Replace with your application code ldi r16, 0x01 sts PORTD_DIRSET, r16 start: inc r16 //anfang: // rjmp weiter // nop //weiter: // rjmp anfang ldi r16, 0x01 sts PORTD_OUTTGL, r16 rjmp start |
Gruß JackFrost
:
Bearbeitet durch User
Ein Hardwarebug im AVR (x)Core - das klingt ja grausam. Ich werde auch versuchen, den BUG nachzustellen: Dazu habe ich mir mal schnell bei Ebay-Artikel Nr. 223522280336 (ich habe nichts mit dem Angebot zu tun - weder ist es von mir noch beziehe ich Provision ...etc..) einen mega32e5 bestellt. MfG Stephan
Stephan B. schrieb: > Ein Hardwarebug im AVR (x)Core - das klingt ja grausam. > > Ich werde auch versuchen, den BUG nachzustellen: Dazu habe ich mir mal > schnell bei > Ebay-Artikel Nr. 223522280336 > (ich habe nichts mit dem Angebot zu tun - weder ist es von mir noch > beziehe ich Provision ...etc..) einen mega32e5 bestellt. > > MfG Stephan Haha, schnell kaufen, bevor sie weg sind. In ein paar Jahren sind die dann richtig Sammlerwert. @Mampf / @TO: gibt es schon einen Zwischenstand von Microchip?
Stephan B. schrieb: > Ebay-Artikel Nr. 223522280336 Ach zu Sch*** ist der teuer (im Vergleich zu 32bit Controllern).
Stefanus F. schrieb: > Stephan B. schrieb: >> Ebay-Artikel Nr. 223522280336 > > Ach zu Sch*** ist der teuer (im Vergleich zu 32bit Controllern). Weil ja auch alle 32-Bit-Controller gleich viel kosten und gleichermaßen billig sind. :-) Ansonsten hat der Ebay-Höker da einfach den Versand und Mindermengenzuschlag eingepreist: wenn man die Teile woanders kauft, kosten sie knapp 3 Euro. Billig sind Xmegas natürlich insgesamt nicht, eigentlich noch nie gewesen.
Jörg W. schrieb: > wenn man die Teile woanders kauft, kosten sie knapp 3 Euro. Schon besser, bei drei Euro hätte ich die Füße still gehalten.
Mal ganz entspannt - warum setzt Du denn überhaupt die E-Serie ein? Für mich ist das ein X-Mega-"Krüppel". Warum nicht die A-Serie?
Hier gibts die für 1 Euro bei Abnahme von 100 Stück: https://www.digikey.de/product-detail/de/microchip-technology/ATXMEGA8E5-M4UR/1611-ATXMEGA8E5-M4URCT-ND/6833447?cur=EUR&lang=de @OssiFant: Ich weiss nicht, ob das an mich addressiert war, aber ich nehme es mal an, da ich hier wohl der einzige bin, der die einsetzt. Der E ist erstmal der günstigste. Zweitens hat er einen verbesserten Kern (leider wohl mit besagtem Bug). Beispiele: 1. 120nA RTC, während alle anderen xmegas um die 1uA ziehen. 2. Du kannst den Clock Takt neuerdings auch durch /6 /10 /12 /24 teilen. Das /10 habe ich sogar schonmal gebraucht, um von exakt 10 MHz auf exakt 1 MHz zu kommen. Das ist mit dem Standardbinärteiler nicht möglich. 3. Die Timer sind komplett anders. Deshalb heissen die hier auch Type 4 und Type 5. Also wenn man mal richtig intensiv mit den xmegas arbeitet, merkt man schon, dass der E ein Testballon für zukünftige Tausendfüssler war.
OssiFant schrieb: > Mal ganz entspannt - warum setzt Du denn überhaupt die E-Serie ein? Für > mich ist das ein X-Mega-"Krüppel". Warum nicht die A-Serie? Ich nutze auch die E Serie wegen der Customer Logic, damit kann man die WS2812 LEDs ohne Bit banging ansteuern. Mein Treiber https://github.com/AndreasBur/Wordclock/tree/master/Wordclock_xmegaForArduino/Wordclock/Wordclock/src/WS2812 basiert auf folgende Idee https://www.ejberg.dk/portfolio/ws2812-xcl/ Gruß Andreas
:
Bearbeitet durch User
Superprofi schrieb: > Stimmt. Und die XCL gibts nur beim E. ...und in ähnlicher Form bei den neuen Tinys und Megas. Wäre auch interessant, ob bei denen der Bug auch auftritt. Die neuen Tinys sind zumindest seitens der Peripherals von den Xmegas abgeleitet, vielleicht gibt es auch Anpassungen des Kerns aus den großen Controllern, die zu den kleinen portiert wurden.
Marcus H. schrieb: > @Mampf / @TO: gibt es schon einen Zwischenstand von Microchip? Nein, bisher noch nicht. Aber: "Status : In Progress" Also mal kucken, vlt kriegen wir schon bald eine Antwort :)
Mampf F. schrieb: ... > Aber: "Status : In Progress" ... Dank Dir. Bin gespannt, wie Microchip an dieser Stelle reagiert.
Mampf F. schrieb: >> @Mampf / @TO: gibt es schon einen Zwischenstand von Microchip? > > Nein, bisher noch nicht. Wass'n, nicht mal einen Firstline-Supporter, der alles haarklein nach AZB-Fehlern absucht?
Angehängte Dateien:
-
20190611_074247.jpg
208 KB, 162 Downloads
Echt witzig - ich kann den Fehler auch bestätigen. Der Bug triggert offenbar nur bei "rjmp" (nimmt man "jmp" stattdessen - Endlosschleife), die Kommandos zwischen den beiden labels scheinen egal... MfG
:
Bearbeitet durch User
Bernd schrieb: > Was passiert, wenn das eine Sprungziel nicht auf Adresse 0 liegt? Was meinst du damit? (Adresse "0" ?) So wie ich das sehe, geht es bei dem Bug um zwei aufeinander-folgende "rjmp". (Wobei das letztere dann nicht ausgeführt wird.) Liegt noch irgendetwas anderes dazwischen, verhält sich alles scheinbar normal (Endlosschleife). Interessant wäre was da passiert - rjmp ist an sich relativ einfach gestickt. Es hat eigentlich keine Nebenfunktionen wie FLAGS ändern oder bedingtes Verhalten... 1) Wird also das 2. rjmp als etwas anderes ausgeführt? (Ändern sich danach unerwartet Registerinhalte oder SREG?) 2) Was passiert, wenn genau vor dem 2. rjmp eine ISR stattdessen betreten wird? Erwartung wäre ja, das es normal behandelt würde (Endlosschleife)... Sobald ich etwas Muse habe, werde ich mal versuchen beides zu testen. (Insofern Microchip nicht vorher aufkllärt...) Nachtrag: 3) Wird ein drittes rjmp nach dem "übersehenem zweiten" wieder ausgeführt?
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten