Mikrocontroller: "Compiler-Optimizer-Fehler" finden?

[Manuel Reimer]

Hallo,

um einen STM32F103 via USB flashen zu kĂśnnen wollte ich mir eigentlich
folgende Bootloader bauen:

https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms

Leider habe ich diesen auch nach vielen Versuchen nie zum Rennen
gebracht. Bis mich jemand auf die Idee gebracht hat statt mit dem, von
meinem Distributor ausgelieferten, GCC 4.9 mal mit GCC 4.8 zu bauen.

Ergebnis: Mit GCC 4.8 läuft der Bootloader plÜtzlich einwandfrei. Mit
einem großen *aber*. Und zwar klappt das ganze nur mit bestimmten
Optimierungs-Einstellungen. Mit "-Os" mit GCC 4.8 gebaut läuft der
Bootloader. Mit "-O3" gebaut läuft das resultierende Binary auch mit GCC
4.8 nicht. Mit GCC 4.9 gebaut bekomme ich, egal welche Einstellungen,
kein lauffähiges Binary hin.

Nach dem Eingrenzungs/Ausschlussverfahren habe ich als erste Kandidaten
fĂźr das Problem diese zwei Zeilen ausgemacht:

https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms/dfu.c#L62
https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms/dfu.c#L63

Zwei eigentlich recht "langweilige" Zuweisungen. Mir will echt nicht in
den Sinn kommen was da das Problem sein soll...

Hat jemand einen Tipp?


Zusätzliche Frage am Rande: Eigentlich wollte ich mich ja schon immer
mal in die Mikrocontroller-Programmierung reinfinden. Wenn ich aber sehe
mit was fĂźr Problemen man da zu tun hat vergeht mir die Lust. Reicht es
von ST-Mikrocontrollern Abstand zu halten oder hat man z.B. bei einem
Atmel ähnliche Probleme?

Danke im Voraus

Gruß

Manuel

 

[Christian Zietz]

Manuel Reimer schrieb:

Nach dem Eingrenzungs/Ausschlussverfahren habe ich als erste Kandidaten
fĂźr das Problem diese zwei Zeilen ausgemacht:

https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms/dfu.c#L62
https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms/dfu.c#L63

Zwei eigentlich recht "langweilige" Zuweisungen. Mir will echt nicht in
den Sinn kommen was da das Problem sein soll...

Hat jemand einen Tipp?

Wie sieht denn der zugehĂśrige Assembler-Quelltext aus, in der
lauffähigen und in der nicht lauffähigen Version? So habe ich vor langer
Zeit mal einen Bug im Optimizer des gcc fĂźr AVR32 gefunden... und gefixt.

Zusätzliche Frage am Rande: Eigentlich wollte ich mich ja schon immer
mal in die Mikrocontroller-Programmierung reinfinden. Wenn ich aber sehe
mit was fĂźr Problemen man da zu tun hat vergeht mir die Lust. Reicht es
von ST-Mikrocontrollern Abstand zu halten oder hat man z.B. bei einem
Atmel ähnliche Probleme?

Compiler-Bugs kann es Ăźberall geben, selbst auf dem PC. Das ist nicht
uC-spezifisch. Wenn Dir deshalb die Lust vergeht, dĂźrfest Du gar nicht
programmieren.

Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

 

[Manuel Reimer]

On 02/18/2015 07:42 PM, Christian Zietz wrote:

Wie sieht denn der zugehĂśrige Assembler-Quelltext aus, in der
lauffähigen und in der nicht lauffähigen Version? So habe ich vor langer
Zeit mal einen Bug im Optimizer des gcc fĂźr AVR32 gefunden... und gefixt.

Wow. Respekt! Mir ist C oft schon zu "nah an der Hardware"...

Funktionierend:

dfuInitXXX:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r2, .L2
ldr r3, .L2+4
str r2, [r3]
ldr r3, .L2+8
add r2, r2, #17408
str r2, [r3]
bx lr
..L3:
.align 2
..L2:
.word 536873984
.word .LANCHOR0
.word .LANCHOR1
.size dfuInitXXX, .-dfuInitXXX
.section .text.dfuInit,"ax",%progbits
.align 2
.global dfuInit
.thumb
.thumb_func
.type dfuInit, %function


Nicht funktionierend:

dfuInitXXX:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
movw r2, #:lower16:.LANCHOR3
mov r0, #3072
movw r3, #:lower16:.LANCHOR4
mov r1, #20480
movt r2, #:upper16:.LANCHOR3
movt r0, 8192
movt r3, #:upper16:.LANCHOR4
movt r1, 8192
str r0, [r2]
str r1, [r3]
bx lr
.size dfuInitXXX, .-dfuInitXXX
.section .text.dfuUpdateByReset,"ax",%progbits
.align 2
.global dfuUpdateByReset
.thumb
.thumb_func
.type dfuUpdateByReset, %function


"dfuInitXXX" ist eine Hilfsfunktion in die ich die zwei Zeilen
ausgelagert habe. So kann ich die Optimierung fĂźr diese eine Funktion
auf "-Os" setzen.

Compiler-Bugs kann es Ăźberall geben, selbst auf dem PC. Das ist nicht
uC-spezifisch. Wenn Dir deshalb die Lust vergeht, dĂźrfest Du gar nicht
programmieren.

Was mir nur etwas Kopfzerbrechen bereitet hat ist die Frage ob hier ein
"volatile" zu viel oder zu wenig schuld sein kĂśnnte. Am PC braucht man
die in aller Regel garnicht.

Gruß

Manuel

 

[Johannes Bauer]

On 18.02.2015 19:34, Manuel Reimer wrote:

Zwei eigentlich recht "langweilige" Zuweisungen. Mir will echt nicht in
den Sinn kommen was da das Problem sein soll...

Wie unterscheiden sich denn die Linkerskripte zwischen den zwei
Compiler-Varianten? Üblicherweise funktioniert das so, im Linkerskript
sind Symbole am Anfang und Ende der Sektionen, die jeweils von Interesse
sind (in deinem Fall wohl .bss oder .data). Die werden dann von C aus
als "extern" irgendwo eingeblendet und deren Adresse verwendet. Also
angenommen im Linkerskript steht

..data : AT (__exidx_end) {
__data_start__ = .;
*(vtable vtable.*)
*(.data .data.*)
*(.gnu.linkonce.d*)
. = ALIGN(4);
__data_end__ = . ;
} >SRAM

Dann steht irgendwo im Startup-Code beispielsweise sowas

extern int __data_start__;
extern int __data_end__;

memcpy(&__data_start__, source, &__data__end - &__data__start);

Wenn die Zuweisungen schief gehen, dann wĂźrde ich mich mal auf die Suche
machen, wozu USER_CODE_RAM expandiert (ich tippe darauf, dass das wie
oben ist) und mich auf machen, im Assembly nachzuprĂźfen was nach dem
Linken da dann tatsächlich fßr Werte drin stehen.

Zusätzliche Frage am Rande: Eigentlich wollte ich mich ja schon immer
mal in die Mikrocontroller-Programmierung reinfinden. Wenn ich aber sehe
mit was fĂźr Problemen man da zu tun hat vergeht mir die Lust. Reicht es
von ST-Mikrocontrollern Abstand zu halten oder hat man z.B. bei einem
Atmel ähnliche Probleme?

Naja, kommt immer ein bischen drauf an. Die 8 Bitter von Atmel kĂśnnen
halt viel weniger sind aber schon einfacher fßr den Anfang. Und hängt
natĂźrlich auch von der Reife der Produkte ab, ich hatte bei EinfĂźhrung
der XMegas auch mal ein Paar extrem fiese Bugs in der gcc-Toolchain
suchen und fixen mĂźssen (IIRC war da beim IRQ-Prolog RAMPD nicht
gesichert worden, das nur in der XMega-Familie präsent ist).

Viele Grüße,
Johannes


--

Wo hattest Du das Beben nochmal GENAU vorhergesagt?
Zumindest nicht Ăśffentlich!

Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos Ăźber RĂźdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

 

[Johannes Bauer]

On 18.02.2015 19:47, Manuel Reimer wrote:

.word .LANCHOR0
.word .LANCHOR1

Das Problem ist, das die Symbole erst vom Linker aufgelĂśst werden und du
nicht weißt, was der einsetzt. Also doch mal komplett kompilieren und
dann disassemblieren, dann weißt du genau was passiert. Kann sein, dass
der Code funktioniert (wenn der Linker das richtige einsetzt), muss aber
nicht.

Am besten wäre es, wenn du mit beiden Compilern Binaries erzeugst und
die dann mit objdump rausdumps und vergleichst. Dann hast du den Fehler
ruckzuck gefunden

Viele Grüße,
Johannes

--

Wo hattest Du das Beben nochmal GENAU vorhergesagt?
Zumindest nicht Ăśffentlich!

Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos Ăźber RĂźdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

 

[Christian Zietz]

Manuel Reimer schrieb:

> Wow. Respekt! Mir ist C oft schon zu "nah an der Hardware"...

Der Fehler war damals einfach auszumachen: Der Optimierer hat eine
Operation einfach wegoptimiert. Der Fix war schon komplizierter, weil
ich dazu ja erst lernen und verstehen musste, nach welchen Regeln der
Optimierer des gcc arbeitet.

Funktionierend:

[...]

Nicht funktionierend:

[...]

Jetzt kenne ich mich mit der Assembler-Syntax von Cortex-M3 leider zu
wenig aus, um dort hinterhältige Bugs zu sehen. Grundsätzlich scheinen
aber in beiden Fällen die selben Werte (0x20000C00 und 0x20005000) an
zwei Speicherstellen geschrieben zu werden. Verweisen denn .LANCHORx auf
die korrekten Adressen? Hast Du die MĂśglichkeit, den Code on-chip zu
debuggen?

"dfuInitXXX" ist eine Hilfsfunktion in die ich die zwei Zeilen
ausgelagert habe. So kann ich die Optimierung fĂźr diese eine Funktion
auf "-Os" setzen.

Dass die Funktion Probleme macht, ist offenbar bekannt, denn es gibt ein
GIT commit " Fixing DFU bugs that makes it compiable with -Os", damit es
Ăźberhaupt mit "-Os" funktioniert, vorher ging wohl nur "-O0".
<https://github.com/tormodvolden/maple-bootloader/commit/f718fee97ab16653e07cd087a94bdd1d7017a7bf>

Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

 

[Reinhard Forster]

Am Wed, 18 Feb 2015 19:53:39 +0100 schrieb Johannes Bauer:

Am besten wäre es, wenn du mit beiden Compilern Binaries erzeugst und
die dann mit objdump rausdumps und vergleichst. Dann hast du den Fehler
ruckzuck gefunden

Kann es sein, dass Du (wie ich) mit (Z80?-)Assemblerprogrammierung groß
geworden bist?

Da Manuel (nach dessen Posting) "C schon oft zu nah an der Hardware" ist,
wird er da wohl Probleme bekommen.

Manuel, nichts fĂźr ungut. Aber es gibt da eines von Murphy's Laws, das
man nur in der Originalsprache rĂźberbringen kann:
"A computer program does what you tell it to do, not what you want it to
do".

Zu meiner Studienzeit war der DWIMš)-Compiler ein beliebtes
Forschungsprojekt ....

Ade

Reinhard

š) Do What I Mean

 

[Olaf Kaluza]

Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> wrote:


>Hat jemand einen Tipp?

Noe. Ich kann dir aber Bestaetigen das es Probleme gibt. Ich habe
gerade ein einfaches Hello-World Programm fuer den STM32F103 (DSO203)
uebersetzt. Da fuehren auch kleinste Aenderungen im Programm dazu das
es entweder problemlos laeuft oder abstuerzt. Oder je nach Optimierung
stuerzt dasselbe Programm ab oder auch nicht.
Bei mit dem 4.7.0.

Ich habe mit demselben Compiler auch schon Sachen fuer den STM32F407
uebersetzt und da sind mir keine Probleme aufgefallen.

Hiermit habe ich es momentan mit dem F103 laufen:

cross-arm-gcc -Wall -O2 -I. -Iinc -Werror -Wno-pointer-sign
-Wno-unused-variable -fomit-frame-pointer -fno-common -mcpu=cortex-m3
-mthumb -msoft-float -mtune=cortex-m3 -mfix-cortex-m3-ldrd
-mstructure-size-boundary=64 -MD -I ../stm/FWLib/inc -c -o Draw.o
Draw.c

Ich will aber nicht nicht ganz ausschliessen das es vielleicht an mir
liegt da dies wirklich die ersten Versuche mit dem F103 sind.

Zusätzliche Frage am Rande: Eigentlich wollte ich mich ja schon immer
mal in die Mikrocontroller-Programmierung reinfinden. Wenn ich aber sehe
mit was für Problemen man da zu tun hat vergeht mir die Lust. Reicht es
von ST-Mikrocontrollern Abstand zu halten oder hat man z.B. bei einem
Atmel ähnliche Probleme?

Ich verwende hier den denselben Sourcecode des 4.7.0er und hab mir
daraus Crosscompiler fuer ARM, SH2, SH2A, M16C, R8C, 68k, 68332 und
AVR erstellt.

Probleme machte bisher nur der F103. Allerdings wuerde ich mit dem
veralteten AVRs keine Zeit mehr verschwenden. Die koennen einfach zu
wenig.

Olaf

 

[Olaf Kaluza]

Christian Zietz <newsgroup.1001@chz.xyz> wrote:

Jetzt kenne ich mich mit der Assembler-Syntax von Cortex-M3 leider zu
wenig aus, um dort hinterhältige Bugs zu sehen. Grundsätzlich scheinen

Das wuerde auch nicht reichen. Bei den modernen Prozessoren muss man
schon tiefer drin stecken um Fehler zu sehen. Besonders wenn es
vielleicht sogar echte Bugs im Prozessor sind um die der Compiler
rumprogrammieren sollte.

Dass die Funktion Probleme macht, ist offenbar bekannt, denn es gibt ein
GIT commit " Fixing DFU bugs that makes it compiable with -Os", damit es
überhaupt mit "-Os" funktioniert, vorher ging wohl nur "-O0".

Der ist auch nicht schlecht: mfix-cortex-m3-ldrd

Olaf

 

[Manuel Reimer]

On 02/18/2015 08:04 PM, Christian Zietz wrote:

Jetzt kenne ich mich mit der Assembler-Syntax von Cortex-M3 leider zu
wenig aus, um dort hinterhältige Bugs zu sehen. Grundsätzlich scheinen
aber in beiden Fällen die selben Werte (0x20000C00 und 0x20005000) an
zwei Speicherstellen geschrieben zu werden.

Passt. So sieht meine "vorgeparste" dfuInitXXX aus:

void dfuInitXXX(void) {
userAppAddr = ((u32)0x20000C00);
userAppEnd = ((u32)0x20005000);
}

Verweisen denn .LANCHORx auf
die korrekten Adressen?

Gute Frage.

Ich frage mich auch, ob ich mit den zwei Zeilen Ăźberhaupt auf dem
richtigen Weg bin. Ich habe schon öfter gesehen, dass Änderungen an ganz
anderen Stellen plĂśtzlich Auswirkung auf die Funktion haben. Irgendwie
ziemlich frustrierend das ganze...

Hast Du die MĂśglichkeit, den Code on-chip zu
debuggen?

In der Theorie hätte ich die Hardware da (ST-Link V2). Ich verwende den
zu Programmieren der Chips. In der Praxis wĂźsste ich mit einem Debugger
aber nichts anzufangen.

Dass die Funktion Probleme macht, ist offenbar bekannt, denn es gibt ein
GIT commit " Fixing DFU bugs that makes it compiable with -Os", damit es
Ăźberhaupt mit "-Os" funktioniert, vorher ging wohl nur "-O0".
https://github.com/tormodvolden/maple-bootloader/commit/f718fee97ab16653e07cd087a94bdd1d7017a7bf

Ja, den Commit kenne ich. Mit dem Commit geht -O0 und -Os aber *nur* mit
GCC 4.8. Mit GCC 4.9 geht garnix...

Schon irgendwo merkwĂźrdig an was man da alles denken soll/muss um diese
STM32 zu programmieren...

Gruß

Manuel

 

[Christian Zietz]

Manuel Reimer schrieb:

Ich frage mich auch, ob ich mit den zwei Zeilen Ăźberhaupt auf dem
richtigen Weg bin.

Nochmal konkret nachgefragt: Du hast diese zwei Zeilen (+ die benĂśtigten
"extern" Verweise auf die Variablen, die ggf. benĂśtigten #defines) in
eine eigene Datei kopiert, richtig? Wenn Du die Optimierer-Einstellungen
nur fßr diese Datei änderst und das resultierende Objekt-File zum sonst
unveränderten Rest linkst, dann geht es mal und mal nicht? Dann musst
tatsächlich herausfinden, an welche Adresse Deine Werte nun geschrieben
werden, wie Johannes schon vorgeschlagen hat.

Hast Du die MĂśglichkeit, den Code on-chip zu
debuggen?

In der Theorie hätte ich die Hardware da (ST-Link V2). Ich verwende den
zu Programmieren der Chips. In der Praxis wĂźsste ich mit einem Debugger
aber nichts anzufangen.

Hm, das wäre halt ein Weg, festzustellen, ob a) die Variablen korrekt
beschrieben werden und sie b) zum Zeitpunkt der späteren Verwendung
immer noch den richtigen Wert haben.

Richtig bÜse wird es, wenn es tatsächlich ein Bug in der CPU ist, der
beim Single-Stepping mit dem Debugger nicht auftritt. Alles schon gehabt...

Ja, den Commit kenne ich. Mit dem Commit geht -O0 und -Os aber *nur* mit
GCC 4.8. Mit GCC 4.9 geht garnix...

Dann hat sich der erzeugte Code also irgendwie geändert. Vergleichen und
SchlĂźsse daraus ziehen.

Schon irgendwo merkwĂźrdig an was man da alles denken soll/muss um diese
STM32 zu programmieren...

Wenn ich Olafs Posting lese, glaube ich auch, dass der STM32F103 evtl.
nicht ganz ausgegoren ist.

Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

 

[Manuel Reimer]

On 02/18/2015 10:14 PM, Christian Zietz wrote:

Nochmal konkret nachgefragt: Du hast diese zwei Zeilen (+ die benĂśtigten
"extern" Verweise auf die Variablen, die ggf. benĂśtigten #defines) in
eine eigene Datei kopiert, richtig?

Nein. Die Funktion steckt in der gleichen Datei. In der zugehĂśrigen ".h"
steht:

void dfuInit(void);
void __attribute__((optimize("Os"))) dfuInitXXX(void);

Aus der "dufInit" rufe ich meine "dfuInitXXX" auf in der diese zwei
Zeile stehen.

Wenn ich das "__attribute__((optimize("Os")))" rausnehme läuft der Code
nicht mehr. Mit dem Attribut läuft alles wie gewßnscht.

Ja, den Commit kenne ich. Mit dem Commit geht -O0 und -Os aber *nur* mit
GCC 4.8. Mit GCC 4.9 geht garnix...

Dann hat sich der erzeugte Code also irgendwie geändert. Vergleichen und
SchlĂźsse daraus ziehen.

Vermutlich hat sich der Code dermaßen umfangreich geändert, dass ich den
relevanten Teil nicht finden werde.

Wenn ich Olafs Posting lese, glaube ich auch, dass der STM32F103 evtl.
nicht ganz ausgegoren ist.

Oder es ist GCC der hier einen Fehler hat. Wenn man so sucht scheinen
die STM32-Controller auch nicht unbedingt extrem verbreitet zu sein.

Wer bei GCC erfolgreich einen Bug melden will sollte aber auf jedem Fall
mindestens den grundlegenden Befehlssatz der betroffenen CPU auswendig
kĂśnnen:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953

Gruß

Manuel

 

[Christian Zietz]

Manuel Reimer schrieb:

Wenn ich das "__attribute__((optimize("Os")))" rausnehme läuft der Code
nicht mehr. Mit dem Attribut läuft alles wie gewßnscht.

Auch wenn das __attribute ja nur lokal auf die Funktion wirken sollte:
Hast Du ßberprßft, dass der Rest des resultierenden Codes tatsächlich
unverändert bleibt? Falls ja, dann bleiben ja wirklich nur noch die zwei
Codezeilen. Bitte prĂźf doch wenigstens -- wie von Johannes vorgeschlagen
-- auf welche Adressen jeweils zugegriffen wird.

Am besten wäre wirklich, den Code einmal im Debugger durchzusteppen.

Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

 

[Sieghard Schicktanz]

Hallo Reinhard,

Du schriebst am 18 Feb 2015 19:24:33 GMT:

Manuel, nichts fĂźr ungut. Aber es gibt da eines von Murphy's Laws, das
man nur in der Originalsprache rĂźberbringen kann:
"A computer program does what you tell it to do, not what you want it to
do".

Warum soll das nur auf Englisch gehen? Auf Deutsch heißt das:
"Ein Computer-Programm tut, was man ihm aufträgt, nicht, was man mÜchte."
(Oder, wenn lieber, auch in der "Du"-Form. Transformation als Leseraufgabe.)

Zu meiner Studienzeit war der DWIMš)-Compiler ein beliebtes
Forschungsprojekt ....

Das ist er doch immer noch.

(BTW: Könnte es sein, daß die Ursache des Problems einfach ist, daß der
funktionierende Code zwischen zwei Registerzugriffen noch bisserl Zeit mit
einer simplen Berechnung verbrät, während der nicht mehr funktionierende
die vorberechneten Werte direkt aufeinanderfolgend in die Register pumpt?)

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Edzard Egberts]

Manuel Reimer wrote:

Ergebnis: Mit GCC 4.8 läuft der Bootloader plÜtzlich einwandfrei. Mit
einem großen *aber*. Und zwar klappt das ganze nur mit bestimmten
Optimierungs-Einstellungen. Mit "-Os" mit GCC 4.8 gebaut läuft der
Bootloader. Mit "-O3" gebaut läuft das resultierende Binary auch mit GCC
4.8 nicht.

Das ist ganz normal und kann Dir auch auf dem PC passieren, ich
optimiere daher immer nur mit maximal "-O2".

Mit GCC 4.9 gebaut bekomme ich, egal welche Einstellungen,
kein lauffähiges Binary hin.

Neue Compiler sind meistens etwas "kritischer" und moppern Ăźber Code,
der schon ewig gut lief. Schmeißt das Ding denn keine Warnungen oder
andere Hinweise?

Nach dem Eingrenzungs/Ausschlussverfahren habe ich als erste Kandidaten
fĂźr das Problem diese zwei Zeilen ausgemacht:

https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms/dfu.c#L62

https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms/dfu.c#L63

Zwei eigentlich recht "langweilige" Zuweisungen. Mir will echt nicht in
den Sinn kommen was da das Problem sein soll...

Hat jemand einen Tipp?

Vor der Zuweisung ist ein Semicolon zu viel, aber das sollte eigentlich
nichts ausmachen. Welchen Wert haben denn die Konstanten?

Mikrocontroller-Programmierung
Reicht es
von ST-Mikrocontrollern Abstand zu halten oder hat man z.B. bei einem
Atmel ähnliche Probleme?

Natßrlich hat man da ähnliche Probleme. Ich habe z.B. eine Notiz
vorliegen "Wegen Bug in den avr-binutils ab 2.20. musste in den
Einstellungen "C/C++ Build" -> "Settings" -> "AVR C++ Linker" ->
"General" die Option "Relax branches" deaktiviert werden", aber auch die
Controller selber schießen einem gerne in den Fuß, wenn man irgend ein
Bit Ăźbersieht. Wer es nicht gewohnt ist, mit Engelsgeduld besonders
sorgfältig zu arbeiten, wird mit Mikrocontrollern wohl nicht so froh...

 

[Matthias Weingart]

Edzard Egberts <ed_09@tantec.de>:

Mit GCC 4.9 gebaut bekomme ich, egal welche Einstellungen,
kein lauffÇĎhiges Binary hin.

Neue Compiler sind meistens etwas "kritischer" und moppern ÇŹber Code,
der schon ewig gut lief. SchmeiÇYt das Ding denn keine Warnungen oder
andere Hinweise?

Hatte mal vor Jahren änliches erlebt mit dem GCC und MSP430; hab den nach
einem Projekt dann aber in die Tonne geworfen und den Compiler von Paul
gekauft (Crossworks); toll war, dass er auch direkter Ansprechpartner für
Bugs war und er die dann auch kurzfristig fixte (meist war das Problem aber
nicht der Compiler, sondern sass hinter meinem Bildschirm . Das machte
dann Spass mit dem Prozessor zu arbeiten.
Naja heute spielt der GCC mit dem MSP430 besser, TI hat auf dem GCC aufbauend
ne kostenlose EntwicklungsSuite auf die Webseite gestellt. Nachteil nun, Paul
verdient mit seinem Compiler kein Geld mehr - aber wenigstens pflegt er ihn
noch. Er lebt jetzt von seinem ARM-Compiler. Vielleicht ist der ja auch ne
Alternative zum gcc für den OP? (crossworks.com)

M.
--

 

[Reinhard Forster]

Am Thu, 19 Feb 2015 00:38:08 +0100 schrieb Sieghard Schicktanz:

man nur in der Originalsprache rĂźberbringen kann: "A computer program
does what you tell it to do, not what you want it to do".

Warum soll das nur auf Englisch gehen? Auf Deutsch heißt das: "Ein
Computer-Programm tut, was man ihm aufträgt, nicht, was man mÜchte."

Geht natĂźrlich auch, klingt aber m. E. irgendwie holprig ...

Ade

Reinhard

 

[Johannes Bauer]

On 18.02.2015 22:24, Manuel Reimer wrote:

Wenn ich Olafs Posting lese, glaube ich auch, dass der STM32F103 evtl.
nicht ganz ausgegoren ist.

Oder es ist GCC der hier einen Fehler hat. Wenn man so sucht scheinen
die STM32-Controller auch nicht unbedingt extrem verbreitet zu sein.

Unter Privatanwendern sind die STM32 sicher noch nicht so verbreitet.
Aber kommerziell kenne ich einige Anwendungen, die ausschließlich auf
CM3 (u.A. STM32) basieren. Und zwar produktiv im Feld und mit gcc Ăźbersetzt.

Wer bei GCC erfolgreich einen Bug melden will sollte aber auf jedem Fall
mindestens den grundlegenden Befehlssatz der betroffenen CPU auswendig
kĂśnnen:

Naja, das ist immer hilfreich. Thumb2 ist zum GlĂźck extrem einfach
gestrickt und sehr schnell zu lernen. Und damit erschlägst du dann die
ganze Familie an neuen Controllern und eine ganze Latte an Herstellern
(TI, NXP, STM, Atmel).

Problematisch an deinem Problem ist, dass es durchaus sein kann, dass
der Compiler so funktioniert, wie er gedacht ist und durch die
aggressiveren Optimierungen einfach Bugs in Code offensichtlich werden.
So sind gerade bei undefiniertem Verhalten (laut C-Standard) einige
Optimierungen dazugekommen, die das ausnutzen. Zum Beispiel ist signed
integer overflow in C undefined behavior (UB), obwohl man's vielleicht
nicht vermutet.

Viel Erfolg,
Johannes

--

Wo hattest Du das Beben nochmal GENAU vorhergesagt?
Zumindest nicht Ăśffentlich!

Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos Ăźber RĂźdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

 

[Johannes Bauer]

On 18.02.2015 20:24, Reinhard Forster wrote:

Am Wed, 18 Feb 2015 19:53:39 +0100 schrieb Johannes Bauer:


Am besten wäre es, wenn du mit beiden Compilern Binaries erzeugst und
die dann mit objdump rausdumps und vergleichst. Dann hast du den Fehler
ruckzuck gefunden

Kann es sein, dass Du (wie ich) mit (Z80?-)Assemblerprogrammierung groß
geworden bist?

Oh Mann, das ist aber lang her

Da Manuel (nach dessen Posting) "C schon oft zu nah an der Hardware" ist,
wird er da wohl Probleme bekommen.

Hm ich finde es schon extrem hilfreich, wenn man das Assembly lesen
kann. Das beantwortet dann auch alle Fragen, wenn sich mal irgendwas
echt komisch verhält oder irgendein IRQ partout nicht funktionieren will
oder sowas.

Viele Grüße,
Johannes


--

Wo hattest Du das Beben nochmal GENAU vorhergesagt?
Zumindest nicht Ăśffentlich!

Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos Ăźber RĂźdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

 

[Olaf Kaluza]

Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> wrote:

Oder es ist GCC der hier einen Fehler hat. Wenn man so sucht scheinen
die STM32-Controller auch nicht unbedingt extrem verbreitet zu sein.

Verbreitet sind die schon. Allerdings sollte das ja eigentlich sogar
egal sein. Der Compiler weiss ja garnicht ob der M3 jetzt von ST ist
oder von einem anderen Lizenznehmern.
Und so wie ST mit Demoboards um sich wirft muss die einfach jemand
verwenden.

Olaf