Forum: Mikrocontroller und Digitale Elektronik XMEGA Hardware-Bug (Kritisch)


von Superprofi (Gast)


Lesenswert?

Hallo,

da ich nur in Assembler programmiere, muss ich höllisch aufpassen, nicht 
aus Versehen in folgenden Hardware-Bug zu laufen:

  2:
  rjmp 1f
  nop
  1:
  rjmp 2b


Kompiliert zu:

  rjmp .+2
  nop
  rjmp .-6


Eigentlich sollte es eine Endlosschleife sein, aber er überspringt den 
letzten rjmp.

Wer jetzt sagt, dass man so ein Konstrukt eh nicht einsetzt, hat 
natürlich recht. Allerdings kommt dieses Konstrukt in abgewandelter Form 
öfters vor, als man denkt:


mainloop:
  1:
  ifnot Gtcc5_overflows,2f
  dec Gtcc5_overflows
  rcall taskmanager_execute_tasks_r31
  rjmp 1b
  2:
  nop ;Komischer HW Bug Work Around...
  rjmp mainloop


Vielleicht mache ich ja auch etwas falsch, aber ich fürchte nicht... :(

(Getestet auf XMEGA E)

: Gesperrt durch Moderator
von Stefan F. (Gast)


Lesenswert?

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:
1
anfang:
2
  rjmp weiter
3
  nop
4
weiter:
5
  rjmp anfang

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


Lesenswert?

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

von Klausi (Gast)


Lesenswert?

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

Gar nicht mal so dumm...

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


Lesenswert?

Stefanus F. schrieb:

> Erstmal benutzt man anständige Namen für Sprungmarken. Und dann benutzt
> man die, dann funktioniert es auch wie erwartet:
>
>
1
> anfang:
2
>   rjmp weiter
3
>   nop
4
> weiter:
5
>   rjmp anfang
6
>

Gut, dass ich nicht "man" bin, denn ich erachte die relativen Labels des 
GNU-Assemblers für sehr praktisch. Ich möchte mir nicht vorstellen, wie 
unübersichtlich ein Assemblerprogramm wird, wenn ich 30 "weiter" und 
"anfang" Labels verwenden müsste. Bei 1f weiß ich sofort, dass an das 
nächste im Programmablauf folgende Label 1 gesprungen wird, welches sich 
aus Lesbarkeitsgründen dann natürlich auch in der folgenden Hand voll 
Codezeilen befinden sollte. Das erachte ich für lesbarer als von 
weiter29 nach anfang30 zu springen.

Grüßle
Volker

von spess53 (Gast)


Lesenswert?

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

von Superprofi (Gast)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

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


Lesenswert?

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

von Peter Petersson (Gast)


Lesenswert?

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

von Dieter R. (drei)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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

: Bearbeitet durch User
von Peter D. (peda)


Lesenswert?

Superprofi schrieb:
> Hardware-Bug

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

von Peter D. (peda)


Lesenswert?

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

von Bernd K. (prof7bit)


Lesenswert?

Selbst ich - und das will was heißen - habe bislang immer gut daran 
getan den spontanen Impuls zu unterdrücken irgendeinen obskuren Bug im 
Compiler/Linker/Assembler/Hardware in die Welt hinaus zu posaunen denn 
nach weiteren 10 Minuten habe ich stets (ausnahmslos!) den Fehler bei 
mir selbst gefunden und somit schon weit mehr als einmal durch bloße 
Willenskraft(!) vermieden mich der Lächerlichkeit preiszugeben.

: Bearbeitet durch User
Beitrag #5861232 wurde von einem Moderator gelöscht.
Beitrag #5861233 wurde von einem Moderator gelöscht.
Beitrag #5861283 wurde von einem Moderator gelöscht.
von Christian Uckold (Gast)


Lesenswert?

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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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)

von OssiFant (Gast)


Lesenswert?

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?

von OssiFant (Gast)


Lesenswert?

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.

von rbx (Gast)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von Sven P. (Gast)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von OssiFant (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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

Wie denn? Dazu fehlen zahlreiche Infos.

von Bernd (Gast)


Lesenswert?

Stefanus F. schrieb:
> Superprofi schrieb im Beitrag #5861232:
>> Hat das überhaupt mal jemand ausprobiert?
>
> Wie denn? Dazu fehlen zahlreiche Infos.

Stell dich nicht so dumm an.

Nimm den Codeabschnitt, starte das Atmel Studio 7, wähle einen µC aus 
und assembliere die paar Zeilen des TOs:
1
  2:
2
  rjmp 1f
3
  nop
4
  1:
5
  rjmp 2b

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

von Stefan F. (Gast)


Lesenswert?

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!

von Notorischer Nachleser (Gast)


Lesenswert?

> 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

von Stefan F. (Gast)


Lesenswert?

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

Mach mal!

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


Lesenswert?

Hallo,

ich habe Deinen Code nun aus einem ATxmega32E5 und einem ATxmega32A4U 
getestet, indem ich folgenden Code aus einem einfachen Dispatcher heraus 
aufgerufen habe:
1
case 'x': USARTD0RomString(TstMsg);
2
          __asm__ __volatile__ ("rjmp .+2");
3
          __asm__ __volatile__ ("nop");
4
          __asm__ __volatile__ ("rjmp .-6");
5
          USARTD0RomString(DoneMsg);
6
  break;
7
case 'y': USARTD0RomString(TstMsg);
8
          __asm__ __volatile__ ("rjmp .+2");
9
          __asm__ __volatile__ ("nop");
10
          __asm__ __volatile__ ("nop");
11
          __asm__ __volatile__ ("rjmp .-8");
12
          USARTD0RomString(DoneMsg);
13
  break;

Auf dem E5 führt nur der zweite Teil, also das Kommando 'y' in eine 
Endlosschleife, auf dem A4U beide.

Grüßle
Volker

von Stefan F. (Gast)


Lesenswert?

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?

von Bernd (Gast)


Lesenswert?

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!

von Stefan F. (Gast)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von Bimbo. (Gast)


Lesenswert?

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

Da liegt dein Problem!

von Stefan F. (Gast)


Lesenswert?

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

von Bimbo. (Gast)


Lesenswert?

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

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


Lesenswert?

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:
1
    case 'x': USARTD0RomString(TstMsg);
2
    2820:       84 e0           ldi     r24, 0x04       ; 4
3
    2822:       92 e0           ldi     r25, 0x02       ; 2
4
    2824:       0e 94 e2 0b     call    0x17c4  ; 0x17c4 <USARTD0RomString>
5
              __asm__ __volatile__ ("rjmp .+2");
6
    2828:       01 c0           rjmp    .+2             ; 0x282c <main+0xd4>
7
              __asm__ __volatile__ ("nop");
8
    282a:       00 00           nop
9
              __asm__ __volatile__ ("rjmp .-6");
10
    282c:       fd cf           rjmp    .-6             ; 0x2828 <main+0xd0>
11
              USARTD0RomString(DoneMsg);
12
    282e:       8c ef           ldi     r24, 0xFC       ; 252
13
    2830:       91 e0           ldi     r25, 0x01       ; 1
14
    2832:       0e 94 e2 0b     call    0x17c4  ; 0x17c4 <USARTD0RomString>
15
    2836:       d5 cf           rjmp    .-86            ; 0x27e2 <main+0x8a>
16
    case 'y': USARTD0RomString(TstMsg);
17
    2838:       84 e0           ldi     r24, 0x04       ; 4
18
    283a:       92 e0           ldi     r25, 0x02       ; 2
19
    283c:       0e 94 e2 0b     call    0x17c4  ; 0x17c4 <USARTD0RomString>
20
              __asm__ __volatile__ ("rjmp .+2");
21
    2840:       01 c0           rjmp    .+2             ; 0x2844 <main+0xec>
22
              __asm__ __volatile__ ("nop");
23
    2842:       00 00           nop
24
              __asm__ __volatile__ ("nop");
25
    2844:       00 00           nop
26
              __asm__ __volatile__ ("rjmp .-8");
27
    2846:       fc cf           rjmp    .-8             ; 0x2840 <main+0xe8>
28
    2848:       f2 cf           rjmp    .-28            ; 0x282e <main+0xd6>

E5 main.lss:
1
 6d8:   0e 94 7d 01     call    0x2fa   ; 0x2fa <USARTD0RomString>
2
 6dc:   c5 cf           rjmp    .-118           ; 0x668 <main+0x84>
3
 6de:   84 eb           ldi     r24, 0xB4       ; 180
4
 6e0:   90 e0           ldi     r25, 0x00       ; 0
5
 6e2:   0e 94 7d 01     call    0x2fa   ; 0x2fa <USARTD0RomString>
6
 6e6:   01 c0           rjmp    .+2             ; 0x6ea <main+0x106>
7
 6e8:   00 00           nop
8
 6ea:   fd cf           rjmp    .-6             ; 0x6e6 <main+0x102>
9
 6ec:   8c ea           ldi     r24, 0xAC       ; 172
10
 6ee:   90 e0           ldi     r25, 0x00       ; 0
11
 6f0:   f3 cf           rjmp    .-26            ; 0x6d8 <main+0xf4>
12
 6f2:   84 eb           ldi     r24, 0xB4       ; 180
13
 6f4:   90 e0           ldi     r25, 0x00       ; 0
14
 6f6:   0e 94 7d 01     call    0x2fa   ; 0x2fa <USARTD0RomString>
15
 6fa:   01 c0           rjmp    .+2             ; 0x6fe <main+0x11a>
16
 6fc:   00 00           nop
17
 6fe:   00 00           nop
18
 700:   fc cf           rjmp    .-8             ; 0x6fa <main+0x116>
19
 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

von Notorischer Nachleser (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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?

von my2ct (Gast)


Lesenswert?

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

von Bimbo. (Gast)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

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


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

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

von Dieter R. (drei)


Lesenswert?

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.

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


Lesenswert?

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

Im Datenblatt 
Atmel-8153K–AVR-ATxmega8E5-ATxmega16E5-ATxmega32E5_Datasheet–08/2016 
findet sich:

Rev. A
* DAC: AREF on PD0 is not available for the DAC
* EDMA: Channel transfer never stops when double buffering is enabled on 
sub-sequent channels
* ADC: Offset correction fails in unsigned mode
* ADC: Averaging is failing when channel scan is enabled
* ADC: Averaging in single conversion requires multiple conversion 
triggers
* ADC accumulator sign extends the result in unsigned mode averaging
* ADC: Free running average mode issue
* ADC: Event triggered conversion in averaging mode
* AC: Flag can not be cleared if the module is not enabled
* USART: Receiver not functional when variable data length and start 
frame detector are enabled
* T/C: Counter does not start when CLKSEL is written
* EEPROM write and Flash write operations fails under 2.0V
* TWI master or slave remembering data
* Temperature Sensor not calibrated


Rev. B
* DAC: AREF on PD0 is not available for the DAC
* ADC: Offset correction fails in unsigned mode
* EEPROM write and Flash write operations fails under 2.0V
* TWI Master or slave remembering data
* TWI SM bus level one Master or slave remembering data
* Temperature Sensor not calibrated
* Automatic port override on PORT C
* Sext timer is not implemented in slave mode

Grüßle
Volker

P.S.: Die von mir gesteste MCU hatte Mask Rev. B und Date Code 1542.
Andere Mask Revs liegen mir nicht vor.

: Bearbeitet durch User
von Peter D. (peda)


Lesenswert?

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.

von Superprofi (Gast)


Lesenswert?

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:
1
main.elf:     file format elf32-avr
2
3
4
Disassembly of section .text:
5
6
00000000 <__ctors_end>:
7
   0:   01 c0           rjmp    .+2             ; 0x4 <Agreen_seg_5>
8
   2:   00 00           nop
9
   4:   fd cf           rjmp    .-6             ; 0x0 <__ctors_end>
10
   6:   00 00           nop
11
   8:   0c 94 52 00     jmp     0xa4    ; 0xa4 <main>
12
   c:   0c 94 37 02     jmp     0x46e   ; 0x46e <isr_unusedint>
13
...

Haben die Herren sonst noch Wünsche?

von Notorischer Nachleser (Gast)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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

von Jens M. (schuchkleisser)


Lesenswert?

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

von Bernd K. (prof7bit)


Lesenswert?

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

nein.

von Notorischer Nachleser (Gast)


Lesenswert?

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

von Notorischer Nachleser (Gast)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von Notorischer Nachleser (Gast)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von Notorischer Nachleser (Gast)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

Notorischer Nachleser schrieb:
> Da Beitrag "Re: XMEGA Hardware-Bug (Kritisch)"
>
> werden unterschiedliche segmente benutzt.
>
Segment != segmentierte Architektur.

Ich weiß es nicht, ich frage. Meine Kenntnis dieser Prozessoren ist 
nicht so tiefgehend. Segmentierte Architektur hatten (haben) z. B. Intel 
x86. Mein nicht besonders fundierter Kenntnisstand ist, dass ARM zwar je 
nach Implementierung Pages kennt, aber keine Segmentierung.

Im Manual section 4.3. steht genau nichts darüber, sondern was über 
Speicherbereiche. Das hat nichts mit der Prozessorarchitektur zu tun.

: Bearbeitet durch User
von Notorischer Nachleser (Gast)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von Notorischer Nachleser (Gast)


Lesenswert?

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

von rbx (Gast)


Lesenswert?

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

von Joachim B. (jar)


Lesenswert?

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!

von Dieter R. (drei)


Lesenswert?

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.

von Notorischer Nachleser (Gast)


Lesenswert?

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.

von Dieter R. (drei)


Lesenswert?

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.

von Joachim B. (jar)


Lesenswert?

Superprofi schrieb:
> 2:
>   rjmp 1f
>   nop
>   1:
>   rjmp 2b
>
> Kompiliert zu:
>
>   rjmp .+2
>   nop
>   rjmp .-6

Dieter R. schrieb:
> Ich seh da keine "Segment"grenze
> oder irgendwas, was bei der PC-Berechnung daneben gehen könnte.

im original Posting gibt es noch keine Adressen, da könnte durchaus was 
über "Segmentgrenzen" passieren!

schon beim Quellcodewechsel vom m328p zu 1284p lief bei fastLED was 
schief, die Ausführungsdauer war 10% größer weil der m1284p ein 
zusätzliches Adressbyte benötigte was die delay.h verfälschte!

Beitrag "Arduino FastLED LIB vs. WS28xx LIB"
Lösung:
Beitrag "Re: Arduino FastLED LIB vs. WS28xx LIB"

: Bearbeitet durch User
von Superprofi (Gast)


Lesenswert?

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.

von OssiFant (Gast)


Lesenswert?

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?

von Superprofi (Gast)


Lesenswert?

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

von Superprofi (Gast)


Lesenswert?

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

von OssiFant (Gast)


Lesenswert?

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.

von OssiFant (Gast)


Lesenswert?

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.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Ok, ich fasse mal zusammen:

Problematische Sequenz:
1
01 C0  00000001 11000000  ; rjmp .+2
2
00 00  00000000 00000000  ; nop
3
FD CF  11111101 11001111  ; rjmp .-6

* Artefakt: Das 2. RJMP wird nicht (immer) ausgeführt.

* Saftware-Kontext: Geschieht auch unmittelbar nach Reset, keine IRQs 
erforderlich.

* Device: ATXmega32E5.  Produktion: 1542 (KW42 2015).  Package: ?

* Takt: 2MHz (intern?), Fuses: ?

* VCC: 3.3V

* Temperatur: ?

Das sollte für den Hersteller ersma genug Info sein, um das in Hardware 
nachvollziehen zu können; immerhin konnte Volker den Bug ohne große Mühe 
bestätigen.  Und je nachdem, wie genau deren Hardware-Simulation ist, 
gibt's dann vielleicht auch mehr Info zu den genauen Bedingungen / 
Befehlssequenzen, in denen der Bug auftreten kann.

Bisher ist AVR ja ziemlich verschont von Core-Bugs, der einzig mir 
bekannte ist der Skip-Bug in uralt-AVRs, für den den Compiler recht 
einfach Work-Arounds einfügen kann.  Bei dem vorliegenden Bug wäre das 
nur auf Assembler-Ebene möglich.

Superprofi schrieb:
> Das ist ja wie Katzen das 1x1 zu erklären.

Vielleicht haben die Experten ja inzwischen verstanden, dass ein 
Silicon-Bug nix mit Coding-Style zu tun hat :-)

von Superprofi (Gast)


Lesenswert?

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.

von Mampf F. (mampf) Benutzerseite


Lesenswert?

Superprofi schrieb:
> Ehrlich gesagt bin ich überrascht, dass heutzutage anscheinend wirklich
> fast keiner mehr Assembler programmiert

Alles persönliche Präferenz ... Früher hab ich alles in Assembler 
geschrieben, aber der avrgcc ist so gut, dass das - meiner Meinung nach 
-  einfach nicht mehr notwendig ist.

Genauso wie du irritiert bist, dass niemand mehr Assembler programmiert, 
sind andere irritiert, weil es noch Menschen gibt, die in Assembler 
programmieren.

Es gibt hier kein Richtig oder Falsch - es sind alles nur Meinungen.

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

Superprofi schrieb:
> Im zuletzt geposteten .lss stehen die absoluten Adressen drin und die
> fängt bei 0 an. Nix mit Segment Jump.

du verstehst es einfach nicht:

der Block

Superprofi schrieb:
> 2:
>   rjmp 1f
>   nop
>   1:
>   rjmp 2b
>
> Kompiliert zu:
>
>   rjmp .+2
>   nop
>   rjmp .-6

könnte ja irgendwo im gesamten Code stehen, am Ende von langen 
Quellcodes also auch kurz vor Segmentgrenzen!
Deswegen ist er hier ja ohne Adressen gezeigt!

Relokatiblen Code hatte ich auch schon 1984 am PC 1500 gemacht, einfach 
weil ich mich nicht festlegen wollte wo meine SW im EEPROM landet!

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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.:
1
> main.elf:     file format elf32-avr
2
> 
3
> Disassembly of section .text:
4
> 
5
> 00000000 <__ctors_end>:
6
>    0:   01 c0           rjmp    .+2             ; 0x4 <Agreen_seg_5>
7
>    2:   00 00           nop
8
>    4:   fd cf           rjmp    .-6             ; 0x0 <__ctors_end>
9
> ...
10
>

also ab Adresse 0 und mit Disassembly und Maschinencode.

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

Johann L. schrieb:
> also ab Adresse 0 und mit Disassembly und Maschinencode.

ein doofes Beispiel ist nun mal kein gutes allgemeingültiges Beispiel.
Was bei Adresse 0 klappt muss nicht überall klappen!

schon mal gar nicht rjump -6

Beitrag "Stromunfall mit Knopfbatterien!" :)

: Bearbeitet durch User
von Dieter R. (drei)


Lesenswert?

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.

von Bernd (Gast)


Lesenswert?

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

von Dieter R. (drei)


Lesenswert?

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

Jetzt bitte nicht wieder die ganze Diskussion von vorne. Hab ich mich 
erst auch gefragt, aber die einfache Antwort ist offensichtlich, dass er 
nach 6-6 springt. Das ist auch logisch.

Siehe .+2, wo springt er wohl hin bzw. soll er hinspringen, das war ja 
das Thema?

: Bearbeitet durch User
Beitrag #5863274 wurde vom Autor gelöscht.
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> Johann L. schrieb:
>> also ab Adresse 0 und mit Disassembly und Maschinencode.
>
> ein doofes Beispiel ist nun mal kein gutes allgemeingültiges Beispiel.
> Was bei Adresse 0 klappt muss nicht überall klappen!

Deshalb auch das Disassembly.  Ist doch genau das, was (zu Recht) 
gefordert wurde? Außerdem hat Volker das Artefakt für eine andere 
Adresse nachvollzogen.  Und Code ab 0x0 hat den Vorteil, dass 
unmittelbar klar ist, dass sich die Hardware bei Codestart direkt nach 
dem Reset befindet, also keine Interrupts freigeschaltet, keine Hardware 
konfiguriert, etc.  Ist für Nachvollziebarkeit doch ideal!

> schon mal gar nicht rjump -6

Das hat auch niemand geschrieben, bitte zitier korrekt!

Da steht:

>    4:   fd cf           rjmp    .-6             ; 0x0 <__ctors_end>

Man beachte das ".", was in Binutils für die aktuelle Position steht,
hier also für 4 (in Einheiten von Bytes).  Und "u" war da auch keins...

Das Argument von RJMP ist k=0xffd, also k=-3. RJMP
ersetzt PC durch PC + k + 1 (siehe AVR Instruction Manual, Einheit dort
ist Words), also durch (Word)adresse 4/2 - 3 + 1 = 0.  objdump rechnet 
die absolute Adresse sogar für dich aus, allerdings als Byte-Adresse: 
0x0.

Wegen dem "+1" in der Semantik von RJMP bezieht sich "." effektiv auf
die Adresse 1 Word nach dem RJMP, daher also ".-6" Bytes (Binutils
verwendet Byte-Adressen) für den Offset, so dass der von objdump 
angezeigte Offset einfach das Doppelte von k ist.

: Bearbeitet durch User
von Notorischer Nachleser (Gast)


Lesenswert?

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.

von Notorischer Nachleser (Gast)


Lesenswert?

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

von Bernd (Gast)


Lesenswert?

Wie kann ich das denn nun nachvollziehen?
Habe avr-as und acra auf der Platte:
1
$ cat rjmptest.asm 
2
.org 0x000
3
hier:
4
    rjmp dort
5
    nop
6
dort:
7
    rjmp hier
8
9
10
$ avr-as -mmcu avrxmega2 -als rjmptest.asm 
11
GAS LISTING rjmptest.asm       page 1
12
13
14
   1                 .org 0x000
15
   2                 hier:
16
   3 0000 00C0            rjmp dort
17
   4 0002 0000            nop
18
   5                 dort:
19
   6 0004 00C0            rjmp hier
20
21
GAS LISTING rjmptest.asm       page 2
22
23
24
DEFINED SYMBOLS
25
        rjmptest.asm:2      .text:0000000000000000 hier
26
        rjmptest.asm:5      .text:0000000000000004 dort
27
28
NO UNDEFINED SYMBOLS

Beitrag #5863330 wurde von einem Moderator gelöscht.
von Superprofi (Gast)


Lesenswert?

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

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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.:
1
$ avr-gcc -x assembler rjmptest.asm -o rjmptest.elf -mmcu=atxmega32e5 -nodefaultlibs -nostartfiles

von Nixmega (Gast)


Lesenswert?

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.

von Bernd (Gast)


Lesenswert?

Johann L. schrieb:
> Das assembliert nur, erzeugt also ein Object-File aber nix Ausführbares;
> zusätzlich muss gelinkt / lokatiert werden.  Am einfachsten geht das,
> indem man avr-gcc als Treiber verwendet, z.B.:
> $ avr-gcc -x assembler rjmptest.asm -o rjmptest.elf -mmcu=atxmega32e5
> -nodefaultlibs -nostartfiles
Ah, danke.
Das sieht besser aus:
1
$ avr-objdump -h -S rjmptest.elf 
2
3
rjmptest.elf:     file format elf32-avr
4
5
Sections:
6
Idx Name          Size      VMA       LMA       File off  Algn
7
  0 .text         00000006  00000000  00000000  00000074  2**1
8
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
9
  1 .data         00000000  00802000  00000006  0000007a  2**0
10
                  CONTENTS, ALLOC, LOAD, DATA
11
12
Disassembly of section .text:
13
14
00000000 <__ctors_end>:
15
   0:  01 c0         rjmp  .+2        ; 0x4 <dort>
16
  ...
17
18
00000004 <dort>:
19
   4:  fd cf         rjmp  .-6        ; 0x0 <__ctors_end>
Morgen schau ich mal, ob ich ein Evalboard mit XMega finde...

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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.

von Notorischer Nachleser (Gast)


Lesenswert?

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.

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


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Superprofi (Gast)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Einer K. (Gast)


Lesenswert?

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.

von Superprofi (Gast)


Lesenswert?

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.

von Superprofi (Gast)


Lesenswert?

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

von knipsi (Gast)


Lesenswert?

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?

von OssiFant (Gast)


Lesenswert?

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

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

von Dieter R. (drei)


Lesenswert?

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?

von OssiFant (Gast)


Lesenswert?

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.

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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

von Dergute W. (derguteweka)


Lesenswert?

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

von Einer K. (Gast)


Lesenswert?

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

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

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

von Bernd K. (prof7bit)


Lesenswert?

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.

von Superprofi (Gast)


Lesenswert?

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

von Superprofi (Gast)


Lesenswert?

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

von Bimbo. (Gast)


Lesenswert?

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.

von AsmHobbyist (Gast)


Lesenswert?

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.

von Bimbo. (Gast)


Lesenswert?

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.

von AsmHobbyist (Gast)


Lesenswert?

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

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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?

von Dieter R. (drei)


Lesenswert?

Marc V. schrieb:
> AsmHobbyist schrieb:
>> Einst scheinst du nicht zu begreifen, ich kann Hochsprachen und kann
>> Klinkersteine kaufen, die Betonmischung selbst anzufertigen und im
>> Assembler zu Programmieren macht MIR Spaß. Shoppen und C nicht.
>
>  Und diese 20KB in Assembler machen genau was?

Pipikram. Noch nicht mal ne Steinzeit-Textverarbeitung. Wordstar hatte 
30 kByte und wurde angeblich in 4 Monaten geschrieben. Von einem (EINEM) 
Programmierer.

Achso: ich bin ja nicht der Threadstarter und darf mir deshalb nur 
verhaltene Kritik erlauben, aber:

1. das gehört mittlerweile eher nicht mehr so richtig zum Thema und

2. wurde der Bug jetzt eigentlich bei Microchip gemeldet?

: Bearbeitet durch User
von H.Joachim S. (crazyhorse)


Lesenswert?

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?

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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:
1
static void flash_green_led(void)
2
{
3
  LED_GN = !LED_GN;
4
}
5
// ...
6
schedule_add_cyclic(flash_green_led, TICKS(0.5));

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

Bernd K. schrieb:
> Marcus H. schrieb:
>> ist es schick,
>> wenn das Listfile von der Struktur her so wie das Quellfile aussieht
>> - wenn man mit der Zulassungsbehörde/dem Kunden nicht über potentielle
>> Compilerfehler reden will
>
> Wie lange dauert es bis ein Beamter in einer Behörde 100kB Assemblercode
> gelesen, verstanden und im Kopf alle denkbaren Codepfade durchgegangen
> ist und auf Fehler abgeklopft hat die dem eigentlichen Autor entgangen
> sein könnten?

Ich hatte keinerlei Codegrößen und auch keine Architekturen genannt.
Stell Dir einfach ein kleines Subsystem vor, welches Teil der 
Infrastruktur für den großen Prozessor nebendran ist.


> Wäre ich der Beamte in der Zulassungsstelle würde ich den Antragsteller
> fragen ob er noch alle Tassen im Schrank hat mit sowas anzurücken. Wenn
> er darauf besteht veranschlage ich die voraussichtliche Zeitdauer der
> Prüfung auf 400 bis 500 Mannjahre, zahlbar im Voraus.

Ich habe bisher bei wirklich keiner benannten Stelle einen Betreuer 
gesehen, der auch nur den Anschein gemacht hätte, jemals so auftreten zu 
wollen, wie Du es hier beschreibst.
Vielleicht, nur vielleicht, liegt es an der Art, wie man mit seinen 
Partnern umgeht? Macht es außerdem nicht Sinn, während der Entwicklung 
mit allen Beteiligten im Dialog zu stehen? Irgendwas zusammenzufrickeln 
und damit in die Zulassung zu gehen ist doch nicht zielführend.

Bei Deiner ganzen Erfahrung im Bereich der Elektronikzertifizierung ist 
Dir noch nie Vorauskasse oder zumindest Anzahlung bei benannten Stellen 
untergekommen?

: Bearbeitet durch User
von Peter D. (peda)


Lesenswert?

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.

von Bernd (Gast)


Lesenswert?

Marcus H. schrieb:
> - welcher Assembler?
> - Codebeispiel plus Listfile
> - welcher Chip
Ja, das hätte ich mir im ersten Beitrag auch gewünscht.

Codebeispiel ist wohl das hier:
1
hier:
2
    rjmp dort
3
    nop
4
dort:
5
    rjmp hier
6
7
neverever:
8
    ; hier kommt was, was nie ausgeführt werden dürfte
9
    ; aber auf XMEGA E doch ausgeführt wird

Digikey findet mit "xmega e" 762 Resultate.
Mouser nur eins: AVR XMEGA E5 Xplained Eval Kit (ATXMEGAE5-XPLD)

Vielleicht ist das gemeint, aber wer weiß das schon, außer dem TO 
(thread opener).

von Dieter R. (drei)


Lesenswert?

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.

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

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.

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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]

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

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

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

Mampf F. schrieb:
> Marcus H. schrieb:
>> Du weißt ja, dass ich bei den AVRs schon seit dem 1200er dabei bin, und
>> das Ausnutzen von Wrapping ist natürlich nichts neues. Xmegas kenne ich
>> nicht, ich bin hier nur wegen des reißerischen Threadnamens
>> reingestolpert.

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

Ah, "kennen" heißt in diesem Kontext: ich hatte noch nicht den Bedarf 
für diese Familie Hardware/Firmware-Entwicklung zu betreiben. Als die 
Teile auf den Markt kamen, war ich mit den STM32 schon fit genug, dass 
AVR und deren Derivate in meinem Umfeld nur noch für sehr wenige 
Anwendungen Sinn gemacht haben. Dann aber bevorzugt die Tinys mit sehr 
kompakten Maschinenprogrammen.
Letzten Herbst hat ein Neukunde eine Entwicklung bei mir bestellt, weil 
er beim vorhandenen Design mit XMEGA128A1 an die Grenzen gekommen war 
und er eine saubere Hardware- und Firmwareplattform für STM32F4 
gebraucht hat. ;)

: Bearbeitet durch User
von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

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?

von Cyblord -. (cyblord)


Lesenswert?

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

Sad but true.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Georg (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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.

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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.

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Jörg W. schrieb:
> Es ist natürlich interessant, dass Atmel es geschafft hat, derart spät
> in der Evolution dieses CPU-Kerns noch einen derartigen Bug zu
> platzieren

Vielleicht haben sie nen anderen Silicon-Bug gefixt, von dem wir (noch) 
nix wissen, und diesen dabei eingebaut :-P

Interessanterweise verfügt der ATxmega32E5 nicht über die 
Read-Modify-Write-Instruktionen (LAS, LAT, LAC, XCH), während der nicht 
betroffene ATxmega32A4U RMW untestützt. Allerdings ist noch nicht 
bekannt, welche Revisions betroffen sind und zu welcher Revision der 
getestete A4U gehört.

Marcus H. schrieb:
> Compilerentwicklungen

Findet momentan praktisch nicht statt, so dass auch trivial zu fixende 
Bugs wie PR86040 unbearbeitet bleiben.

Marcus H. schrieb:
> Bei den AVRs gibt es neue Tinys (z.B. ATtiny414), deren CPU [...]

Ist ne normale Xmega CPU.  Ob Atmochip nen µC "Tiny" oder "Mega" nennt 
hängt nicht am Instruktionssatz oder Anzahl GPRs, sondern wieviel 
Beinchen das Ding hat.

> [...] und Speichermodell neu ist.

Gefühlt 15 Jahre zu spät.  Bereits die Reduced Tiny hatten ein lineares 
Speichermodell (z.B. ATtiny40, deren ISA unterstützt noch nichtmal LPM). 
Linearisierung ist also ohne Nebeneffekte (wie z.B. langsamere 
Instruktionen bzw. Speicherzugriff) machbar.


Mampf F. schrieb:
> Skip Instruction with Interrupts
> A skip instruction (SBRS, SBRC, SBIS, SBIC, CPSE)
> that skips a two-word instruction needs three clock
> cycles. If an interrupt occurs during the first or second
> clock cycle of this skip instruction, the return address
> will not be stored correctly on the stack.

Den kann der Compiler einfach umgehen, z.B:
1
char i;
2
3
void store (char c)
4
{
5
    if (c)
6
        i = 0;
7
}

ATmega128
1
store:
2
  cpse r24,__zero_reg__
3
  sts i,__zero_reg__
4
  ret

ATmega103
1
store:
2
  tst r24
3
  breq .L2
4
  sts i,__zero_reg__
5
.L2:
6
  ret
oder in der libgcc:
1
#ifdef __AVR_ERRATA_SKIP_JMP_CALL__
2
    tst     SS
3
    brpl    4f
4
#else
5
    sbrc    SS, 7
6
#endif
7
    XCALL   __negdi2
8
4:
Auf Assembler-Ebene gibt's ne Warnung bei so einem Konstrukt:
1
__asm ("sbrc 0,0 $ lds 0,0");
2
Assembler messages:
3
Warning: skipping two-word instruction

Den neuen Bug kann man auf Compilerebene jedoch nicht umgehen; schon 
deshalb weil ein RJMP-NOP-RJMP mit C/C++ nicht erzeugbar ist; wobei wir 
hier die Antwort abwarten müssen, welcher Sequenzen genau betroffen 
sind.

Marcus H. schrieb:
> Ein Verdacht den ich hatte basiert darauf, dass wir eine
> Speicherstruktur haben, bei der das Wrapping nicht so funktioniert,
> wie es beim Assembler eingestellt ist.

Ich wette auf die Pipeline.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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.

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

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

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Jörg W. schrieb:
>> Johann L. schrieb:
>>> Ich wette auf die Pipeline.
>>
>> So viel Pipeline hat ein AVR ja eigentlich gar nicht
>
> Soweit ich weiß eine 2-stufige Pipeline.  Natürlich nicht für den
> Anwender sichtbar (die einzige Instruktion, für die das ISA-Manual keine
> feste Zeit angibt, ist SPM.  Und das hat bestimmt nix mit der Pipeline
> zu tun).

Jedes AVR Datenblatt hat doch ein Kapitel "Functional Description" - da 
sieht man doch wie das Timing ist und warum Jumps mindestens zwei Takte 
brauchen.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

Jörg W. schrieb:
> Marcus H. schrieb:
>> Damit sollte das Thema Assemblerfehler vom Tisch sein.
>
> Das war nie ein Thema, denn die generierten Befehle hatte der TO ja mit
> angegeben.

Der Ausschnitt aus dem Listfile kam im 52. Post. Bei dieser Art 
Fehlerbeschreibung wäre es professionell, den Hexcode und die 
Infrastruktur im Eingangspost zu nennen.

> Sein Stil mag nicht OK sein, aber dass man sich anschließend
> daran hochzog, dass er Unix-Assembler-mäßige f/b-Labels benutzt hat (die
> hat ja keineswegs der GAS erst erfunden, die gab es schon Jahre davor
> auch bei x86/Unix), war ein völlig unsinniger Nebenschauplatz.

Die f/b Labels werden AFAIK von Atmel Studio 7 bis einschließlich V7.0 
nicht unterstützt. Für den Nichteingeweihten lenkt das vom Thema ab. 
Noch gibt es Windows-Benutzer hier im Forum.


Insgesamt ein wichtiger Thread mit vollkommen unnötig verplemperter Zeit 
durch die Präsentationsform. Man versetze sich in die Lage eines 
Supportmitarbeiters, der sowas bearbeiten muss.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Marcus H. schrieb:

> Der Ausschnitt aus dem Listfile kam im 52. Post.

Der generierte Code steht im ersten, wenn auch fälschlich als 
"compilierter" bezeichnet, aber mit wenig Phantasie kann man sich das 
zusammenreimen.

> Die f/b Labels werden AFAIK von Atmel Studio 7 bis einschließlich V7.0
> nicht unterstützt.

Atmel Studio ist ein Editor bzw. eine IDE.

Dass der Atmel-Assembler das nicht unterstützt, ist richtig. Der war und 
ist seit Jahrzehnten halt sehr primitiv gehalten. Bspw. kann hat er 
keinen Linker und arbeitet rein absolut, ohne verschieblichen 
Objektcode, den Assembler schon vor vielen Jahrzehnten beherrscht haben.

Auch in Atmel Studio kann man den GNU Assembler benutzen, denn die 
GCC-Toolchain wird ohnehin typischerweise mit installiert. Zumindest 
darf man als Assemblerprogrammierer ruhig auch mal soweit über den 
Tellerrand blicken, dass man bei den genannten Labels nicht gleich in 
Zweifel stellt, dass sie funktionieren oder festlegt, sie seien unsinnig 
(zweites Posting). Im dritten Posting war zumindest dann die korrekte 
Vermutung geäußert, wie sie denn funktionieren, aber trotzdem wird 
danach weiterhin auf dem TO herumgehackt, weil er dieses Feature seines 
Assemblers benutzt und auch sonst nicht so schön schreibt, wie manch 
einer sich das wünscht. Dass es sich tatsächlich um einen Siliziumbug 
handelt, will lange Zeit gar keiner wahr haben …

: Bearbeitet durch Moderator
von Stefan F. (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

von Drei, unterwegs (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Drei, unterwegs (Gast)


Lesenswert?

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.

von Superprofi (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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

von Superprofi (Gast)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

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?

von Superprofi (Gast)


Lesenswert?

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

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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?

von OssiFant (Gast)


Lesenswert?

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

... oder Deinem Assembler ...

von OssiFant (Gast)


Lesenswert?

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.

von Bastian W. (jackfrost)


Lesenswert?

Hallo,

Ich hab folgendes mal auf einem XMEGA32e5 getestet:
1
.include <ATxmega32e5def.inc>
2
; Replace with your application code
3
ldi r16, 0x01 
4
sts PORTD_DIRSET, r16
5
start:
6
    inc r16
7
anfang:
8
 rjmp weiter
9
 nop
10
weiter:
11
 rjmp anfang
12
 ldi r16, 0x01
13
 sts PORTD_OUTTGL, r16
14
rjmp start

Was zu folgenden compiliert :
1
00008000  LDI R16,0x01    Load immediate 
2
00008001  STS 0x0661,R16    Store direct to data space 
3
00008003  INC R16    Increment 
4
00008004  RJMP PC+0x0002    Relative jump 
5
00008005  NOP     No operation 
6
00008006  RJMP PC-0x0002    Relative jump 
7
00008007  LDI R16,0x01    Load immediate 
8
00008008  STS 0x0667,R16    Store direct to data space 
9
0000800A  RJMP PC-0x0007    Relative jump

Den Block am Ende
1
 ldi r16, 0x01
2
 sts PORTD_OUTTGL, r16
3
rjmp start

wird genau einmal ausgeführt und dann ist der XMEGA in der 
Endlosschleife.
Egal wie viele nops ich einfüge es wird einmal ausgeführt.

Wenn ich die Entlosschleife entferne sieht man das togglen gut am Oszi.

Gruß JackFrost

von Superprofi (Gast)


Lesenswert?

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

von OssiFant (Gast)


Lesenswert?

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.

von Bastian W. (jackfrost)


Lesenswert?

OssiFant schrieb:
> Warum springst Du zu "start" zurück? Wenn Du nur toggeln willst ist das
> nicht erforderlich.

Der Sprung zu Start ist nur drinnen wenn der Bug vorhanden da ist müsste 
der uC die Endlosschleife
1
anfang:
2
 rjmp weiter
3
 nop
4
weiter:
5
 rjmp anfang

ingnorieren und dann sollte der Pin toggeln. Es wird aber nur einmal 
ausgeführt und dann bleibt er in dem Block da oben.

Eigentlich dürfte er da nie hinkommen und der Pin müsste immer low sein.

Auch mit
1
anfang:
2
 rjmp weiter
3
 nop
4
weiter:
5
 rjmp anfang
6
 nop
7
 nop 
8
 nop
9
 nop
10
 nop
11
 nop

Wird das toggle einmal ausgeführt und dann nie wieder.

Superprofi schrieb:
>>00008006  RJMP PC-0x0002    Relative jump
>
> Ich kenne die Arbeitsweise deines Assemblers nicht, aber bei mir steht
> da
>
>> 4:   fd cf           rjmp    .-6
>
> Sieht für mich nach einem anderen Sprungziel aus.

Es ist der AVR Assembler aus dem Atmelstudio 7.

Gruß JackFrost

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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.

von Bastian W. (jackfrost)


Lesenswert?

Ich hab das Hexfile mit dem ODA dissasembliert.
1
.data:00000000 01 e0        ldi  r16, 0x01  ; 1
2
.data:00000002 00 93 61 06  sts  0x0661, r16
3
.data:00000006 03 95        inc  r16
4
.data:00000008 01 c0        rjmp .+2      ;  0x0000000c
5
.data:0000000a 00 00        nop
6
.data:0000000c fd cf        rjmp .-6        ;  0x00000008
7
.data:0000000e 01 e0        ldi  r16, 0x01  ; 1
8
.data:00000010 00 93 67 06  sts  0x0667, r16
9
.data:00000014 f8 cf        rjmp .-16       ;  0x00000006

Und als Intelhex
1
:020000020000FC
2
:1000000001E000936106039501C00000FDCF01E00F
3
:0600100000936706F8CF23
4
:00000001FF

Gruß JackFrost

: Bearbeitet durch User
von Bastian W. (jackfrost)


Lesenswert?

Johann L. schrieb:
> Interessant,  Hast du Revision / DateCode des ATxmega32E5?

Das ist komisch, weil im Hex ist as ja 0x0000.

Die Fuse für den Bootloader war auf Bootsektion gestellt, dann zeigt das 
Atmel Studio 7 als Start 0x8000 im Disassmbliertem Code an. Wenn die 
Fuse auf App section steht 0x0000.

Es ändert sich aber nichts am Verhalten

Gruß JackFrost

: Bearbeitet durch User
von Bastian W. (jackfrost)


Lesenswert?

Wenn ich das laden von 0x01 in R16 vor den rjmp ziehe dann bleibt der 
XMega direkt in der Endlosschleife
1
.include <ATxmega32e5def.inc>
2
; Replace with your application code
3
ldi r16, 0x01 
4
sts PORTD_DIRSET, r16
5
start:
6
    inc r16
7
anfang:
8
 rjmp weiter
9
 nop
10
weiter:
11
ldi r16, 0x01
12
 rjmp anfang
13
// ldi r16, 0x01
14
 sts PORTD_OUTTGL, r16
15
rjmp start

Gruß JackFrost

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Superprofi (Gast)


Angehängte Dateien:

Lesenswert?

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

von Bastian W. (jackfrost)


Lesenswert?

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 :
1
.include <ATxmega32e5def.inc>
2
; Replace with your application code
3
ldi r16, 0x01 
4
sts PORTD_DIRSET, r16
5
start:
6
    inc r16
7
anfang:
8
 rjmp weiter
9
 nop
10
weiter:
11
ldi r16, 0x01
12
 rjmp anfang
13
// ldi r16, 0x01
14
 sts PORTD_OUTTGL, r16
15
rjmp start

Bei dem geht sie an, toggelt aber nicht
1
.include <ATxmega32e5def.inc>
2
; Replace with your application code
3
ldi r16, 0x01 
4
sts PORTD_DIRSET, r16
5
start:
6
    inc r16
7
anfang:
8
 rjmp weiter
9
 nop
10
weiter:
11
12
 rjmp anfang
13
 ldi r16, 0x01
14
 sts PORTD_OUTTGL, r16
15
rjmp start

Und hier toggelt sie , was sie auch soll
1
.include <ATxmega32e5def.inc>
2
; Replace with your application code
3
ldi r16, 0x01 
4
sts PORTD_DIRSET, r16
5
start:
6
    inc r16
7
//anfang:
8
// rjmp weiter
9
// nop
10
//weiter:
11
12
// rjmp anfang
13
 ldi r16, 0x01
14
 sts PORTD_OUTTGL, r16
15
rjmp start

Gruß JackFrost

: Bearbeitet durch User
von Stephan B. (matrixstorm)


Lesenswert?

Ein Hardwarebug im AVR (x)Core - das klingt ja grausam.

Ich werde auch versuchen, den BUG nachzustellen: Dazu habe ich mir mal 
schnell bei 
https://www.ebay.de/itm/ATXMEGA32E5-AU-AVR-Mikrocontroller-EEPROM-1kB-SRAM-4kB-Flash-32kB-ATMEL/223522280336?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 
(ich habe nichts mit dem Angebot zu tun - weder ist es von mir noch 
beziehe ich Provision ...etc..) einen mega32e5 bestellt.

MfG Stephan

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

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
> 
https://www.ebay.de/itm/ATXMEGA32E5-AU-AVR-Mikrocontroller-EEPROM-1kB-SRAM-4kB-Flash-32kB-ATMEL/223522280336?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649
> (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?

von Stefan F. (Gast)


Lesenswert?

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

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von OssiFant (Gast)


Lesenswert?

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?

von Superprofi (Gast)


Lesenswert?

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.

von Andreas B. (andreas_b395)


Lesenswert?

OssiFant schrieb:
> Mal ganz entspannt - warum setzt Du denn überhaupt die E-Serie ein? Für
> mich ist das ein X-Mega-"Krüppel". Warum nicht die A-Serie?

Ich nutze auch die E Serie wegen der Customer Logic, damit kann man die 
WS2812 LEDs ohne Bit banging ansteuern.

Mein Treiber 
https://github.com/AndreasBur/Wordclock/tree/master/Wordclock_xmegaForArduino/Wordclock/Wordclock/src/WS2812 
basiert auf folgende Idee https://www.ejberg.dk/portfolio/ws2812-xcl/

Gruß Andreas

: Bearbeitet durch User
von Superprofi (Gast)


Lesenswert?

Stimmt. Und die XCL gibts nur beim E.

von Superprofi (Gast)


Lesenswert?

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

von Hmmm (Gast)


Lesenswert?

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.

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

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

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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?

von Stephan B. (matrixstorm)


Angehängte Dateien:

Lesenswert?

Echt witzig - ich kann den Fehler auch bestätigen.

Der Bug triggert offenbar nur bei "rjmp" (nimmt man "jmp" stattdessen - 
Endlosschleife), die Kommandos zwischen den beiden labels scheinen 
egal...

MfG

: Bearbeitet durch User
von Bernd (Gast)


Lesenswert?

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

von Stephan B. (matrixstorm)


Lesenswert?

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

Was meinst du damit? (Adresse "0" ?)

So wie ich das sehe, geht es bei dem Bug um zwei aufeinander-folgende 
"rjmp".
(Wobei das letztere dann nicht ausgeführt wird.)
Liegt noch irgendetwas anderes dazwischen, verhält sich alles scheinbar 
normal (Endlosschleife).

Interessant wäre was da passiert - rjmp ist an sich relativ einfach 
gestickt. Es hat eigentlich keine Nebenfunktionen wie FLAGS ändern oder 
bedingtes Verhalten...

1) Wird also das 2. rjmp  als etwas anderes ausgeführt? (Ändern sich 
danach unerwartet Registerinhalte oder SREG?)

2) Was passiert, wenn genau vor dem 2. rjmp eine ISR stattdessen 
betreten wird? Erwartung wäre ja, das es normal behandelt würde 
(Endlosschleife)...

Sobald ich etwas Muse habe, werde ich mal versuchen beides zu testen.
(Insofern Microchip nicht vorher aufkllärt...)

Nachtrag:
3) Wird ein drittes rjmp nach dem "übersehenem zweiten" wieder 
ausgeführt?

: Bearbeitet durch User
von Carl D. (jcw2)


Lesenswert?

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

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

von Stephan (Gast)


Lesenswert?

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

Kann ich beantwortenm mit: Endlosschleife

bei:
1
[...]
2
  /* corebug? */
3
  asm volatile (
4
  "loop%=:    \n\t"
5
  "  rjmp  jump%=  \n\t"
6
  "  nop    \n\t"
7
  "  break    \n\t"
8
  "  ret    \n\t"
9
  "jump%=:    \n\t"
10
  "  rjmp  loop%=  \n\t"
11
  "  rjmp  loop%=  \n\t"
12
    :
13
    :
14
    : "memory"
15
  );
16
[...]

MfG

von Stephan (Gast)


Lesenswert?

Hmm, folgendes triggert den Bug: (KEINE Endlosschleife - letztes rjmp 
skipped)
1
  asm volatile (
2
  "rjmp .+2 \n\t"
3
  "nop    \n\t"
4
  "rjmp .-6 \n\t"
5
  );

Und folgendes funktioniert scheinbar korekt:
1
  asm volatile (
2
  "rjmp .+0 \n\t"
3
  "rjmp .-4 \n\t"
4
  );

MfG

Beitrag #5872560 wurde vom Autor gelöscht.
von Venkman (Gast)


Lesenswert?

Aus Interesse: push


Was hat sich denn ergeben?

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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

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

Beitrag #5893835 wurde von einem Moderator gelöscht.
von Dieter R. (drei)


Lesenswert?

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

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

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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

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

: Wiederhergestellt durch Moderator
Beitrag #5894148 wurde von einem Moderator gelöscht.
Beitrag #5894154 wurde von einem Moderator gelöscht.
von YAG (Gast)


Lesenswert?

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

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

Wobei vielleicht gerade das hilft -> ;).

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

von Mampf F. (mampf) Benutzerseite


Lesenswert?

1
I tried testing the scenarios at my end and I was unable to successfully build the code in Atmel Studio. I changed to below sequence and it worked properly.
2
3
rjmp PC+2
4
5
nop
6
7
rjmp PC-2
8
9
This worked with both single nop and multiple nop’s. Are you checking with Atmel Studio 7? The syntax didn’t work and failed with errors when I tried rjmp .+2 in Atmel Studio assembler.

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

Muss da nochmal darauf antworten :/

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

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

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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

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

l1:
  rjmp l2
  nop
l2:
  rjmp l1

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

von Stefan F. (Gast)


Lesenswert?

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

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

von Dieter R. (drei)


Lesenswert?

Mampf F. schrieb:

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

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

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

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Dieter R. schrieb:

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

Schon lange, und auch einen Teil der Softwareentwicklung.

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

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

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

: Bearbeitet durch Moderator
Beitrag #5909110 wurde von einem Moderator gelöscht.
Beitrag #5909114 wurde von einem Moderator gelöscht.
Beitrag #5909129 wurde von einem Moderator gelöscht.
Beitrag #5909133 wurde von einem Moderator gelöscht.
Beitrag #5909135 wurde vom Autor gelöscht.
Beitrag #5909144 wurde von einem Moderator gelöscht.
Beitrag #5909146 wurde von einem Moderator gelöscht.
Beitrag #5909148 wurde von einem Moderator gelöscht.
Beitrag #5909150 wurde von einem Moderator gelöscht.
Beitrag #5909152 wurde von einem Moderator gelöscht.
Beitrag #5909164 wurde von einem Moderator gelöscht.
Beitrag #5909177 wurde von einem Moderator gelöscht.
Beitrag #5909190 wurde von einem Moderator gelöscht.
Beitrag #5909193 wurde von einem Moderator gelöscht.
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

Beitrag #5909203 wurde von einem Moderator gelöscht.
von Dieter R. (drei)


Lesenswert?

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

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

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

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

von Holm T. (Gast)


Lesenswert?

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

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

Gruß,

Holm

von rbx (Gast)


Lesenswert?

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

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

von H.Joachim S. (crazyhorse)


Lesenswert?

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

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

Beitrag #5909969 wurde von einem Moderator gelöscht.
von Peter D. (peda)


Lesenswert?

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

Beitrag #5909989 wurde von einem Moderator gelöscht.
Beitrag #5910092 wurde von einem Moderator gelöscht.
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

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

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

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

: Bearbeitet durch Moderator
Beitrag #5910210 wurde von einem Moderator gelöscht.
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

von Mampf F. (mampf) Benutzerseite


Lesenswert?

Neue Infos:

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


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

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

Was machen wir nun? :-)

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

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

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

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


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

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Lesenswert?

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

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

von Christopher J. (christopher_j23)


Lesenswert?

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

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

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

von Stefan F. (Gast)


Lesenswert?

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

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

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

von Christopher J. (christopher_j23)


Lesenswert?

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

: Bearbeitet durch User
von Bastian W. (jackfrost)


Lesenswert?

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

Gruß JackFrost

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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

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

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

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

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

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

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

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

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

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

von Jan (Gast)


Lesenswert?

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

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

von Jan (Gast)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

Sollen wir zusammen weinen?
Dieses Nachtreten hilft doch niemanden.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

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

von Moby (Gast)


Lesenswert?

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

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

von Stephan B. (matrixstorm)


Lesenswert?

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

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

MfG

von Peter D. (peda)


Lesenswert?

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

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

von Moby (Gast)


Lesenswert?

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

Interessanterweise führt ein
1
m1: rjmp m2
2
jmp xx
3
m2: rjmp m1

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

von Mampf F. (mampf) Benutzerseite


Lesenswert?

Ah, Thread wieder aktiv :)

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

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

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

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.