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)
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:
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
Stefanus F. schrieb:> Erstmal benutzt man anständige Namen für Sprungmarken. Und dann benutzt> man die, dann funktioniert es auch wie erwartet:>>
1
> anfang:
2
> rjmp weiter
3
> nop
4
> weiter:
5
> rjmp anfang
6
>
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
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
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?
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.
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.
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:
1
2:
2
rjmp 1f
3
nop
4
1:
5
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!
Hallo,
ich habe Deinen Code nun aus einem ATxmega32E5 und einem ATxmega32A4U
getestet, indem ich folgenden Code aus einem einfachen Dispatcher heraus
aufgerufen habe:
1
case'x':USARTD0RomString(TstMsg);
2
__asm____volatile__("rjmp .+2");
3
__asm____volatile__("nop");
4
__asm____volatile__("rjmp .-6");
5
USARTD0RomString(DoneMsg);
6
break;
7
case'y':USARTD0RomString(TstMsg);
8
__asm____volatile__("rjmp .+2");
9
__asm____volatile__("nop");
10
__asm____volatile__("nop");
11
__asm____volatile__("rjmp .-8");
12
USARTD0RomString(DoneMsg);
13
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?
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.
>> da ich nur in Assembler programmiereBimbo. 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:
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
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.
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:
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.
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: https://www.youtube.com/watch?v=7FeqF1-Z1g0
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?
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.
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:
https://www.youtube.com/watch?v=CHq2fzE4ryI
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 .-6Dieter 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"
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:
1
01 C0 00000001 11000000 ; rjmp .+2
2
00 00 00000000 00000000 ; nop
3
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.
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!
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!" :)
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?
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.
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 ....
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.:
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:
1
$ avr-objdump -h -S rjmptest.elf
2
3
rjmptest.elf: file format elf32-avr
4
5
Sections:
6
Idx Name Size VMA LMA File off Algn
7
0 .text 00000006 00000000 00000000 00000074 2**1
8
CONTENTS, ALLOC, LOAD, READONLY, CODE
9
1 .data 00000000 00802000 00000006 0000007a 2**0
10
CONTENTS, ALLOC, LOAD, DATA
11
12
Disassembly of section .text:
13
14
00000000 <__ctors_end>:
15
0: 01 c0 rjmp .+2 ; 0x4 <dort>
16
...
17
18
00000004 <dort>:
19
4: fd cf rjmp .-6 ; 0x0 <__ctors_end>
Morgen schau ich mal, ob ich ein Evalboard mit XMega finde...
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:> 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 ChipBeitrag "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?
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:
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?
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:
1
hier:
2
rjmp dort
3
nop
4
dort:
5
rjmp hier
6
7
neverever:
8
; hier kommt was, was nie ausgeführt werden dürfte
9
; 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. ;)
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?
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.
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:
1
chari;
2
3
voidstore(charc)
4
{
5
if(c)
6
i=0;
7
}
ATmega128
1
store:
2
cpse r24,__zero_reg__
3
sts i,__zero_reg__
4
ret
ATmega103
1
store:
2
tst r24
3
breq .L2
4
sts i,__zero_reg__
5
.L2:
6
ret
oder in der libgcc:
1
#ifdef __AVR_ERRATA_SKIP_JMP_CALL__
2
tst SS
3
brpl 4f
4
#else
5
sbrc SS, 7
6
#endif
7
XCALL __negdi2
8
4:
Auf Assembler-Ebene gibt's ne Warnung bei so einem Konstrukt:
1
__asm("sbrc 0,0 $ lds 0,0");
2
Assemblermessages:
3
Warning:skippingtwo-wordinstruction
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.
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.
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.
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 …
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.
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.
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?
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?
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:
1
.include <ATxmega32e5def.inc>
2
; Replace with your application code
3
ldi r16, 0x01
4
sts PORTD_DIRSET, r16
5
start:
6
inc r16
7
anfang:
8
rjmp weiter
9
nop
10
weiter:
11
rjmp anfang
12
ldi r16, 0x01
13
sts PORTD_OUTTGL, r16
14
rjmp start
Was zu folgenden compiliert :
1
00008000 LDI R16,0x01 Load immediate
2
00008001 STS 0x0661,R16 Store direct to data space
3
00008003 INC R16 Increment
4
00008004 RJMP PC+0x0002 Relative jump
5
00008005 NOP No operation
6
00008006 RJMP PC-0x0002 Relative jump
7
00008007 LDI R16,0x01 Load immediate
8
00008008 STS 0x0667,R16 Store direct to data space
9
0000800A RJMP PC-0x0007 Relative jump
Den Block am Ende
1
ldi r16, 0x01
2
sts PORTD_OUTTGL, r16
3
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
1
anfang:
2
rjmp weiter
3
nop
4
weiter:
5
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
1
anfang:
2
rjmp weiter
3
nop
4
weiter:
5
rjmp anfang
6
nop
7
nop
8
nop
9
nop
10
nop
11
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
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.
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
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 :
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.
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.
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:>> @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?
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
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?
Thread beobachten
Seitenaufteilung abschalten