XMEGA Hardware-Bug (Kritisch)

[Superprofi (Gast)]

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)

[Stefan ⛄ F. (stefanus)]

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

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

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

[Klausi (Gast)]

1f könnte Zieladresse 1 "f"orwärts und 2b Zieladresse 2 "b"ückwärts 
heissen.

Gar nicht mal so dumm...

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

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

[spess53 (Gast)]

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

[Superprofi (Gast)]

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.

[Dieter R. (drei)]

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.

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

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 (Gast)]

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. :)

[Dieter R. (drei)]

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.

[Bernd K. (prof7bit)]

Und was hat das ganze übrigens mit "Hardware-Bug" zu tun wenn in 
Wirklichkeit nur Dein komischer Assembler sich verrechnet? Welcher 
Assembler überhaupt?

[Peter D. (peda)]

Superprofi schrieb:
> Hardware-Bug

Woher willst Du das wissen?
Zeig mal den erzeugten Code.

[Peter D. (peda)]

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

[Bernd K. (prof7bit)]

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.

[Christian Uckold (Gast)]

Darf ich mal fragen, wieso du "nur in Assembler" programmierst?

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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)

[OssiFant (Gast)]

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?

[OssiFant (Gast)]

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.

[rbx (Gast)]

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.

[Dieter R. (drei)]

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.

[Sven P. (Gast)]

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.

[Dieter R. (drei)]

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.

[OssiFant (Gast)]

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.

[Stefan ⛄ F. (stefanus)]

Superprofi schrieb im Beitrag #5861232:
> Hat das überhaupt mal jemand ausprobiert?

Wie denn? Dazu fehlen zahlreiche Infos.

[Bernd (Gast)]

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.

[Stefan ⛄ F. (stefanus)]

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!

[Notorischer Nachleser (Gast)]

> 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

[Stefan ⛄ F. (stefanus)]

Bernd schrieb:
> Es ist ganz leicht den TO zu bestätigen bzw. zu widerlegen. Man muss es
> nur wollen.

Mach mal!

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

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

[Stefan ⛄ F. (stefanus)]

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?

[Bernd (Gast)]

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!

[Stefan ⛄ F. (stefanus)]

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.

[Dieter R. (drei)]

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.

[Bimbo. (Gast)]

Superprofi schrieb:
> Hallo,
>
> da ich nur in Assembler programmiere

Da liegt dein Problem!

[Stefan ⛄ F. (stefanus)]

>> 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?

[Bimbo. (Gast)]

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? ;)

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

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

[Notorischer Nachleser (Gast)]

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.

[Stefan ⛄ F. (stefanus)]

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?

[my2ct (Gast)]

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

[Bimbo. (Gast)]

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.

[Dieter R. (drei)]

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.

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

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

[Stefan ⛄ F. (stefanus)]

Irgendwie finde ich dazu kein Errata Dokument. Das müsste doch hier 
sein, oder nicht? https://www.microchip.com/wwwproducts/en/ATxmega32e5

[Dieter R. (drei)]

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.

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

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.

[Peter D. (peda)]

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.

[Superprofi (Gast)]

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?

[Notorischer Nachleser (Gast)]

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.

[Dieter R. (drei)]

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.

[Dieter R. (drei)]

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.

[Stefan ⛄ F. (stefanus)]

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).

[Jens M. (schuchkleisser)]

- 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?

[Bernd K. (prof7bit)]

Superprofi schrieb:
> Es wurde auch nach kompiliertem Code gefragt. Der wurde aber im
> Anfangsposting geliefert, direkt aus dem .lss.

nein.

[Notorischer Nachleser (Gast)]

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

[Notorischer Nachleser (Gast)]

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.

[Dieter R. (drei)]

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.

[Notorischer Nachleser (Gast)]

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.

[Dieter R. (drei)]

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.

[Notorischer Nachleser (Gast)]

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.

[Dieter R. (drei)]

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.

[Notorischer Nachleser (Gast)]

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.

[Dieter R. (drei)]

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.

[Notorischer Nachleser (Gast)]

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

[rbx (Gast)]

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..)

[Joachim B. (jar)]

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!

[Dieter R. (drei)]

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.

[Notorischer Nachleser (Gast)]

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.

[Dieter R. (drei)]

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.

[Joachim B. (jar)]

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"

[Superprofi (Gast)]

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.

[OssiFant (Gast)]

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?

[Superprofi (Gast)]

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 (Gast)]

Ach ich bin raus. Das ist ja wie Katzen das 1x1 zu erklären.

[OssiFant (Gast)]

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.

[OssiFant (Gast)]

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.

[Johann L. (gjlayde)]

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 :-)

[Superprofi (Gast)]

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.

[Mampf F. (mampf)]

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.

[Joachim B. (jar)]

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. (gjlayde)]

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.

[Joachim B. (jar)]

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!" :)

[Dieter R. (drei)]

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 (Gast)]

Johann L. schrieb:
> 4:   fd cf           rjmp    .-6
Und wo bitteschön soll der Core bei 4 - 6 hinspringen?

[Dieter R. (drei)]

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?

[Johann L. (gjlayde)]

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.

[Notorischer Nachleser (Gast)]

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.

[Notorischer Nachleser (Gast)]

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 (Gast)]

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

[Superprofi (Gast)]

@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.

[Johann L. (gjlayde)]

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

[Nixmega (Gast)]

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.

[Bernd (Gast)]

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...

[Johann L. (gjlayde)]

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.

[Notorischer Nachleser (Gast)]

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.

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

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

[Peter D. (peda)]

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.

[Peter D. (peda)]

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.

[Superprofi (Gast)]

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.

[Bernd K. (prof7bit)]

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.

[Peter D. (peda)]

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.

[Arduino Fanboy D. (ufuf)]

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.

[Superprofi (Gast)]

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.

[Superprofi (Gast)]

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

[knipsi (Gast)]

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?

[OssiFant (Gast)]

Superprofi schrieb:
> Und das in Assembler! Ich persönlich find das absolut geil :D

Ja - Makro-King - und Du..schwätzer :-)

[Dieter R. (drei)]

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 (Gast)]

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.

[Marc V. (Firma: Vescomp) (logarithmus)]

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...

[Dergute W. (derguteweka)]

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

[Arduino Fanboy D. (ufuf)]

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.
;-)

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

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

[Bernd K. (prof7bit)]

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.

[Superprofi (Gast)]

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".

[Superprofi (Gast)]

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)"

[Bimbo. (Gast)]

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.

[AsmHobbyist (Gast)]

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.

[Bimbo. (Gast)]

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.

[AsmHobbyist (Gast)]

>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.

[Marc V. (Firma: Vescomp) (logarithmus)]

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?

[Dieter R. (drei)]

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?

[H.Joachim S. (crazyhorse)]

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?

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

@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.

[Peter D. (peda)]

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));

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

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?

[Peter D. (peda)]

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.

[Bernd (Gast)]

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).

[Dieter R. (drei)]

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.

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

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.

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

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.

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

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.

[Mampf F. (mampf)]

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]

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

Mampf F. schrieb:
> XMEGAs haben keine Vorteile gegenüber Cortex-M

Für einen ausgemachten Assemblerprogrammierer schon: er muss seinen Code 
nicht neu schreiben. :-))

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

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. ;)

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

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?

[Cyblord -. (cyblord)]

Mampf F. schrieb:
> [troll-modus] Muss man nicht kennen ... XMEGAs haben keine Vorteile
> gegenüber Cortex-M[/troll-modus]

Sad but true.

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

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.

[Georg (Gast)]

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.

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

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.

[Mampf F. (mampf)]

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.

[Mampf F. (mampf)]

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.

[Mampf F. (mampf)]

Ich hab den Bug auf Microchip gemeldet - mal schauen, was raus kommt.

[Johann L. (gjlayde)]

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.

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

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.

[Johann L. (gjlayde)]

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.

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

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

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

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.

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

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.

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

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.

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

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 …

[Stefan ⛄ F. (stefanus)]

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.

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

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

[Drei, unterwegs (Gast)]

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.

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

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.

[Drei, unterwegs (Gast)]

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.

[Superprofi (Gast)]

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.

[Peter D. (peda)]

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.

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

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.

[Stefan ⛄ F. (stefanus)]

Ich habe leider nur einen Xmega A und ein paar Xmega D vorrätig.

[Superprofi (Gast)]

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!"

[Stefan ⛄ F. (stefanus)]

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 (Gast)]

Ich habe damals keinen Kontakt mit dem Hersteller gesucht, da ich damals 
davon ausgegangen bin, dass der Fehler irgendwo bei mir liegt.

[Mampf F. (mampf)]

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?

[OssiFant (Gast)]

Mampf F. schrieb:
> Und du hast ein Jahr gebraucht, um herauszufinden, dass der Fehler nicht
> bei dir liegt?

... oder Deinem Assembler ...

[OssiFant (Gast)]

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. (jackfrost)]

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

[Superprofi (Gast)]

>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.

[OssiFant (Gast)]

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.

[Bastian W. (jackfrost)]

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

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

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.

[Johann L. (gjlayde)]

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.

[Bastian W. (jackfrost)]

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

[Bastian W. (jackfrost)]

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

[Bastian W. (jackfrost)]

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

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

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.

[Superprofi (Gast)]

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

[Bastian W. (jackfrost)]

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

[Stephan B. (matrixstorm)]

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

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

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?

[Stefan ⛄ F. (stefanus)]

Stephan B. schrieb:
> Ebay-Artikel Nr. 223522280336

Ach zu Sch*** ist der teuer (im Vergleich zu 32bit Controllern).

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

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.

[Stefan ⛄ F. (stefanus)]

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.

[OssiFant (Gast)]

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?

[Superprofi (Gast)]

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.

[Andreas B. (andreas_b395)]

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

[Superprofi (Gast)]

Stimmt. Und die XCL gibts nur beim E.

[Superprofi (Gast)]

Für die Nicht-Insider: XCL = XMEGA Custom Logic.

[Hmmm (Gast)]

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.

[Mampf F. (mampf)]

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 :)

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

Mampf F. schrieb:
...
> Aber: "Status :  In Progress"
...

Dank Dir. Bin gespannt, wie Microchip an dieser Stelle reagiert.

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

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?

[Stephan B. (matrixstorm)]

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 (Gast)]

Was passiert, wenn das eine Sprungziel nicht auf Adresse 0 liegt?

[Stephan B. (matrixstorm)]

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?