uint64_t auf STM32F103

[Doran S. (utzer)]

Hallo,

ich implementiere gerade einen Algorithmus auf einem STM32F103. Dabei 
müssen leider großen Integer verarbeitet werden. Sobald ich allerdings 
uint64_t statt uint32_t in meinem Programm verwende, läuft das ganze 
Programm nicht mehr! Selbst der Teil vor der ersten Verwendung von 
uint64_t wird nicht ausgeführt, der Mikrocontroller bleibt komplett 
still.
Woran kann das liegen?

Ich benutze den arm-none-eabi-gcc und im Anhang ist mein makefile.

Vielen Dank für weiterführende Tipps.

[Frank M. (ukw) (Moderator)]

Doran S. schrieb:
> Ich benutze den arm-none-eabi-gcc und im Anhang ist mein makefile.

Du meinst, der Bug steckt im Makefile?

[Stefan F. (Gast)]

> Woran kann das liegen?

Am Makefile kann man das nicht erkennen.

Abgesehen davon: Der Dateiname sollte mit einem "M" beginnen, nicht "m".

[Oliver S. (oliverso)]

Vermutlich steht in Zeile 42 des source codes oder linker scripts oder 
startup codes "if uint64_t, then fail"...

Oliver

[Doran S. (utzer)]

Hallo,

hatte vermutet, dass eventuell eine Compiler-Option fehlerhaft sein 
könnte, daher das Makefile...

Der Code, der Ärger macht sieht so aus:

write_byte(0x04);    // FTWO 45.01MHz
write_byte(0x5C);
write_byte(0x2E);
write_byte(0x33);
write_byte(0xF0);

uint32_t FTW = (uint32_t)(((uint64_t)(0x100000000) * (uint64_t)(freq)) / ((uint64_t)(125000)));
write_byte(0x04);    // FTWO
write_byte(0xFF & (FTW >> 24));
write_byte(0xFF & (FTW >> 16));
write_byte(0xFF & (FTW >> 8));
write_byte(0xFF & FTW);

Die stdint.h ist natürlich eingebunden. Woran könnte der Fehler liegen?

[Stefan F. (Gast)]

Doran S. schrieb:
> Woran könnte der Fehler liegen?

Kann man an diesem kleinen Schnipsel nicht sehen.

Zur Ratekiste würde ich hinzufügen: Speicherüberlauf

Eventuell hilft  es, sich die Warnungen des Compilers anzuschauen.

[Falk B. (falk)]

Doran S. schrieb:
> uint32_t FTW = (uint32_t)(((uint64_t)(0x100000000) * (uint64_t)(freq)) /
> ((uint64_t)(125000)));

Sicher daß deine DDS mit 125kHz läuft? Oder sind es nicht eher 125 MHz?

[Doran S. (utzer)]

Hallo,

Ja, der DDS läuft natürlich mit 125MHz. Ich rechne aber in kHz, daher 
passt das. Der Fehler muss aber in der gezeigten Zeile liegen, denn wenn 
ich diese Zeile z.B. durch

uint32_t FTW = 0x5C28F5C3;

 ersetze, dann geht alles.

Ich kann auch z.B. den Compiler-Output bereitstellen, oder den gesamten 
Quellcode, falls dies hilft? Was benötigt ihr?

[Vincent H. (vinci)]

Wie groß is freq?

[Oliver S. (oliverso)]

Am C-Code iegt es in der Zeile nicht. Wenn Ram insgesamt knapp ist, 
könnten die 64-Bit-Routinen natürlich das Faß zum überlaufen bringen, 
aber so wirklich glaube ich da nicht dran.

Oliver

[Doran S. (utzer)]

Hallo,

der RAM ist sehr gering ausgelastet, der Linker gibt folgendes aus:

Memory region         Used Size  Region Size  %age Used
           Flash:        5312 B       256 KB      2.03%
           SRAM0:          28 B        64 KB      0.04%

freq = 14000.

Hat sonst noch jemand Tipps?
So sieht die entsprechende Stelle disassembliert aus:

    uint32_t FTW = (uint32_t)(((uint64_t)(0x100000000) * (uint64_t)(freq)) / ((uint64_t)(125000)));
 8000d2a:  2300        movs  r3, #0
 8000d2c:  4a1a        ldr  r2, [pc, #104]  ; (8000d98 <configure_AD9951+0xd8>)
 8000d2e:  4629        mov  r1, r5
 8000d30:  4620        mov  r0, r4
 8000d32:  f7ff f9e3   bl  80000fc <__aeabi_uldivmod>
 8000d36:  4605        mov  r5, r0

Vielen Dank schon mal.

[M. Н. (Gast)]

Stefan F. schrieb:
>> Woran kann das liegen?
>
> Am Makefile kann man das nicht erkennen.
>
> Abgesehen davon: Der Dateiname sollte mit einem "M" beginnen, nicht "m".

Die meisten Windows-User haben noch nie davon gehört, dass Dateinamen 
case-sensitiv sein können. Bei Windows ist es egal, wie das (M/m)akefile 
heißt.

[Stefan F. (Gast)]

Doran S. schrieb:
> der RAM ist sehr gering ausgelastet

Das sagt noch nichts darüber aus, wie viel RAM dynamisch zur Laufzeit 
belegt wird.

[Vincent H. (vinci)]

(4294967296 * 14000) / 12500 != 1546188227 (0x5C28F5C3)

[leo (Gast)]

Doran S. schrieb:
>  8000d2e:  4629        mov  r1, r5
>  8000d30:  4620        mov  r0, r4
>  8000d32:  f7ff f9e3   bl  80000fc <__aeabi_uldivmod>

Das ist sicher keine 64bit Operation. Aber dividiere mal freq und 
125.000 vorher durch 1000, dann koennte es passen.

leo

[Doran S. (utzer)]

Vincent H. schrieb:
> (4294967296 * 14000) / 12500 != 1546188227 (0x5C28F5C3)

Das stimmt, aber:
(4294967296 * 14000) / 125000 = 481036337 (0x1CAC0831).
Und auch wenn ich

uint32_t FTW = (uint32_t)(((uint64_t)(0x100000000) * (uint64_t)(freq)) / ((uint64_t)(125000)));

durch

uint32_t FTW = 0x1CAC0831;

ersetze, funktioniert es. Das Problem muss deshalb in der Berechnung 
liegen...

Hat noch jemand einen Tipp?

[Mr.T (Gast)]

Doran S. schrieb:
> der Mikrocontroller bleibt komplett still.
Glaub ich nicht. Springt in eine Exception (Hard Fault,...)?
Ich hatte mit uint64_t auf IAR EWARM nie Probleme mit dem F103.

[Mr.T (Gast)]

Springt er in eine Exception (Hard Fault,...)?

[(prx) A. K. (prx)]

leo schrieb:
> Das ist sicher keine 64bit Operation.

Ich denke doch. r1:r0 /% r3:r2

 8000d2a:  2300        movs  r3, #0
 8000d2c:  4a1a        ldr  r2, [pc, #104]  ; (8000d98 <configure_AD9951+0xd8>)

vmtl steht an Adresse 8000d98 der Wert 125000

 8000d2e:  4629        mov  r1, r5
 8000d30:  4620        mov  r0, r4

vmtl das Produkt von vorher

[(prx) A. K. (prx)]

Frank M. schrieb:
> Du meinst, der Bug steckt im Makefile?

Vielleicht. Wenn er die falsche Lib erwischt.

[Doran S. (utzer)]

An Adresse 080000fc steht:

080000fc <__aeabi_uldivmod>:
 80000fc:  b953        cbnz  r3, 8000114 <__aeabi_uldivmod+0x18>
 80000fe:  b94a        cbnz  r2, 8000114 <__aeabi_uldivmod+0x18>
 8000100:  2900        cmp  r1, #0
 8000102:  bf08        it  eq
 8000104:  2800        cmpeq  r0, #0
 8000106:  bf1c        itt  ne
 8000108:  f04f 31ff   movne.w  r1, #4294967295  ; 0xffffffff
 800010c:  f04f 30ff   movne.w  r0, #4294967295  ; 0xffffffff
 8000110:  f000 b97a   b.w  8000408 <__aeabi_idiv0>
 8000114:  f1ad 0c08   sub.w  ip, sp, #8
 8000118:  e96d ce04   strd  ip, lr, [sp, #-16]!
 800011c:  f000 f806   bl  800012c <__udivmoddi4>
 8000120:  f8dd e004   ldr.w  lr, [sp, #4]
 8000124:  e9dd 2302   ldrd  r2, r3, [sp, #8]
 8000128:  b004        add  sp, #16
 800012a:  4770        bx  lr

Leider kenne ich mich mit Assembler nicht so aus. Hilft dies weiter?

[Doran S. (utzer)]

Mr.T schrieb:
> Springt er in eine Exception (Hard Fault,...)?

Habe versucht, eine LED im Hard Fault Handler blinken zu lassen, aber da 
kommt nichts...

[(prx) A. K. (prx)]

Doran S. schrieb:
> 800011c:  f000 f806   bl  800012c <__udivmoddi4>

Dann mach da mal weiter. Der Code oben testet nur auf Division durch 0.

[Doran S. (utzer)]

An Adresse 800012c steht eine sehr lange Funktion, siehe Datei anbei.

[Dennis (Gast)]

Doran S. schrieb:
> uint32_t FTW = (uint32_t)(((uint64_t)(0x100000000) * (uint64_t)(freq)) /
> ((uint64_t)(125000)));

schreibe doch mal statt dessen folgendes:

uint32_t FTW = (uint32_t)(((uint64_t)(0x10000000) * (uint64_t)(freq)) 
/((uint64_t)(125000)));

...wenn es läuft: dann war ein Null zuviel dran

[Niklas G. (erlkoenig)]

Vielleicht ist es das alte Stack-Alignment-Problem. Zeig mal das ganze 
Linkerscript und den Startupcode. Was sagt der Debugger zum Crash? 
Hard-Fault? Register-Inhalte, insb. SP? An welcher Stelle crasht es 
genau?

[Doran S. (utzer)]

Was ist das "alte Stack-Alignment-Problem"? Das kenne ich nicht.

Das Linker-Skript sieht so aus:

ENTRY(_reset)

MEMORY {
  Flash (rx):  ORIGIN = 0x08000000, LENGTH = 256K
  SRAM0 (rwx): ORIGIN = 0x20000000, LENGTH = 64K
}

_stack_end = ORIGIN(SRAM0) + LENGTH(SRAM0);

SECTIONS {
  .text : {
    _text_section_start = .;
    KEEP(*(._vectors))
    *(.text)
    *(.text*)
    *(.rodata .rodata.* .constdata .constdata.*)
    _text_section_end = .;
  } > Flash
  
  . = ALIGN(4);
  
  .bss : {
    _bss_section_start = .;
    *(.bss)
    *(.bss*)
    _bss_section_end = .;
  } > SRAM0
    
  . = ALIGN(4);
    
  .data : {
    _data_section_start = .;
    *(.data)
    *(.data*)
    _data_section_end = .;
  } > SRAM0 AT > Flash
}

[Doran S. (utzer)]

Mit dem Debugger kann ich leider nicht ran, weil die Hardware nur einen 
UART-Anschluss hat (über den ich flashe). Gibt es Alternativen? Kann man 
das irgendwie simulieren?

[Niklas G. (erlkoenig)]

Doran S. schrieb:
> Was ist das "alte Stack-Alignment-Problem"? Das kenne ich nicht.

Bei manchen Beispiel-Linker-Scripten von ST ist der initiale 
Stack-Pointer falsch gesetzt, sodass er ein falsches Alignment hat, und 
dann das Speichern von 64bit-Werten auf dem Stack scheitert. Das scheint 
hier aber nicht der Fall zu sein.

Doran S. schrieb:
> Mit dem Debugger kann ich leider nicht ran, weil die Hardware nur einen
> UART-Anschluss hat

Fehler Nr. 1 beim Hardware-Design...

Doran S. schrieb:
> Gibt es Alternativen? Kann man
> das irgendwie simulieren?

z.B. mit einem anderen STM32F103-Board. Keil µVision kann auch STM32 
simulieren.

[Doran S. (utzer)]

Wenn ich das gesamte Projekt als gepacktes Archiv hochlade, könnte dann 
jemand, der eine Hardware mit Debug-Möglichkeit hat, das mal bei sich 
ausprobieren? Vielleicht hat ja mein Controller einen Hardware-Schaden?

[Stefan F. (Gast)]

Doran S. schrieb:
> Wenn ich das gesamte Projekt als gepacktes Archiv hochlade,

Ich schätze, der Betreiber des Forums würde sich freuen, wenn du das 
über Dropbox oder einen ähnlichen Dienst machst, wegen der Größe.

[Doran S. (utzer)]

Hallo,

habe noch so ein Board gefunden: 
https://www.reichelt.de/evaluationboard-stm32-value-line-discovery-stm32-vldiscov-p219361.html?&trstct=pos_14
Darauf habe ich das selbe Problem. Man kann also die Hardware 
ausschließen.

Auf dem Board ist ja ein ST-Link. Kann ich damit debuggen?

[Stefan F. (Gast)]

Doran S. schrieb:
> Auf dem Board ist ja ein ST-Link. Kann ich damit debuggen?

Ja

[Doran S. (utzer)]

Hallo,

ich komme einfach nicht weiter. In Keil uVision muss ich mich erst 
einarbeiten. Anbei jedoch das komplette Programm als Disassemble. Wer 
darin den Fehler findet und mir beibringen kann, was schief gelaufen 
ist, bekommt von mir ein 1X16 LCD als Weihnachtsgeschenk zugesendet.

[STM Apprentice (Gast)]

Doran S. schrieb:
> ich komme einfach nicht weiter.

Welche IDE benutzt du?

Mache ein "clean" (allo *.obj, *.o, *.bin etc) und komprimiere
dein Projekt in ein Zip-File, setze es hier rein, es findet sich
sicher jemand der es nachprüfen kann. So gross kann dein Projekt
nicht sein dass es nicht hier up- und downloadbar sein könnte.

[STM Apprentice (Gast)]

Doran S. schrieb:
> Wer darin den Fehler findet .....

Ich werde mir das nicht antun, das vorher angebotene jedoch schon.

[Doran S. (utzer)]

Hallo,

anbei das komplette Projekt als ZIP-Archiv. Ich benutze keine IDE, 
sondern gebe im Terminal "make" ein.

[STM Apprentice (Gast)]

Doran S. schrieb:
> Ich benutze keine IDE,
> sondern gebe im Terminal "make" ein.

Gut, ich baue ein Projekt daraus und melde mich dann.
Vielleicht macht es jemand anders auch auf anderem Weg ....

[STM Apprentice (Gast)]

Doran S. schrieb:
> anbei das komplette Projekt als ZIP-Archiv.

Lässt sich leider nicht auf die Schnelle debuggen da ein Teil
des Codes die Ports der SWD Schnittstelle umprogrammiert und
man somit keinen Zugriff aufs Debuggen hat.

[Doran S. (utzer)]

Hallo,

oh, das habe ich übersehen. Im Anhang eine Version ohne Deaktivierung 
der Debug-Schnittstelle. Das Problem besteht trotzdem noch.

[STM Apprentice (Gast)]

Ist es ein BluePill Board das du verwendest?

Wenn nicht, welchen Controller genau verwendest du?

[Doran S. (utzer)]

Es ist eine selbst entwickelte Platine. Der Controller ist der 
STM32F103RCT6.

[STM Apprentice (Gast)]

Doran S. schrieb:
> oh, das habe ich übersehen. Im Anhang eine Version ohne Deaktivierung
> der Debug-Schnittstelle.

Nein, ist immer noch der gleiche Code.

Tut mir leid, ich bin raus.

[Doran S. (utzer)]

Hallo,

das tut mir Leid, ich habe aber tatsächlich in der letzten Version keine 
Deaktivierung der Debug-Schnittstelle mehr drin. Die Datei STM32F100.c 
ist entsprechend angepasst.

Vielen Dank aber trotzdem für Deine Mühe. Bin eh ganz durcheinander, 
weil ich das heute den ganzen Tag versucht habe. Vielen Dank für die 
Tipps von allen Seiten.

Das Angebot steht aber noch.

[STM Apprentice (Gast)]

Doran S. schrieb:
> das tut mir Leid, ich habe aber tatsächlich in der letzten Version keine
> Deaktivierung der Debug-Schnittstelle mehr drin.

Diese Deaktivierung muss ja einen Sinn haben, wozu wird es
überhaupt gemacht wenn man es auch weglassen kann?

[Doran S. (utzer)]

Hallo,

an PA13, PA14 und PA15 hängt Peripherie. Deshalb brauche ich diese als 
"normale" Ausgänge. Wenn ich es wieder aktiviere, dann funktioniert 
natürlich manche Peripherie nicht mehr, aber der Fehler, dass der 
Mikrocontroller kein Programm mehr ausführt, besteht immer noch.

// PA13, PA14 and PA15 as normal GPIO
RCC->APB2ENR |= (0x01 << 0);
AFIO->MAPR |= (0x04 << 24);

Diese Zeilen habe ich darum in der zweiten Version auskommentiert.

Wenn Du noch weitere Infos brauchst, kann ich diese natürlich liefern.

Viele Grüße!

[Dieter Graef (Gast)]

ändere mal eine Zeile im makefile zu
LDFLAGS += -lgcc # more options, e.g. libraries

in der libgcc sind die Routinen für uint64_t drin

Gruss
Dieter

[STM Apprentice (Gast)]

Gut, ich habe deine Sourcen in ein Projekt auf Basis des
BluePill Boards (F103C8T6) eingebunden. Es compiliert
einwandfrei, durchläuft die Initialisierung ohne Probleme,
ebenso wird die Hauptschleife zyklisch abgearbeitet. Keine
Hänger oder Hard Faults.

Anbei das lauffähige Projekt für Embitz. Verwende das, du
wirst sehen das geht relativ einfach und du hast den Debugger
gleich mit eingebaut.

Wenn es mit der Einstellung (F103C8T6) nicht gleich
funktioniert musst du noch den richtigen Controller im
Projekt einstellen.

Im Code ist also kein prinzipieller Fehler enthalten, es muss
dann wohl an deinem Linker Description File liegen, oder
was anderem was ich beim Bau des Projekts nicht berücksichtigt
habe.

[OT512 (Gast)]

Was passiert, wenn FTW = 0 ist?
Vielleicht entwickelt der Compiler (uint64_t)(0x100000000) zu Null?

Im verbesserten Code steht auch: (uint64_t)(0x100000000ul)...

[STM Apprentice (Gast)]

OT512 schrieb:
> Im verbesserten Code steht auch: (uint64_t)(0x100000000ul)...

Das habe ich sicherheitshalber hinzugefügt.

Sonst ist da nichts "verbessert".

[Oliver S. (oliverso)]

OT512 schrieb:
> Vielleicht entwickelt der Compiler (uint64_t)(0x100000000) zu Null?

Dann wäre es kein C oder C++ Compiler.

Oliver

[Johannes S. (Gast)]

Doran S. schrieb:
> (0x04 << 24);

Wird das nicht 0?

[(prx) A. K. (prx)]

Johannes S. schrieb:
>> (0x04 << 24);
>
> Wird das nicht 0?

Bei 16-Bittern schon. Aber nicht bei einem 32-Bitter.

[Johannes S. (Gast)]

beim gcc auf einem F407 mit gcc kompiliert wird das richtig gerechnet:

    uint64_t freq = 14000;
    uint32_t FTW = (uint32_t)((0x100000000ULL * freq) / 125000ULL);
    printf("testvar: %lx\n", FTW);

output:
testvar: 1cac0831

[Markus (Gast)]

Stell mal den Datentyp von uint64_t auf int64_t um.
Wenn ich mich recht erinnere, hatte ich schon mal Probleme bei der 
Division festgestellt.

[Oliver S. (oliverso)]

Man könnte auch Räucherstäbchen anzünden, und einen Datentyp-Voodoo-Tanz 
aufführen.

Oliver

[Doran S. (utzer)]

Hallo,

vielen Dank für die hilfreichen Antworten an alle.
Also, wenn ich das EmBitz-Projekt von STM Apprentice kompiliere (und mit 
"stm32flash -w F103_uint64_Test.hex -v -R -i -dtr,rts,-rts:dtr,rts,-rts 
/dev/ttyUSB0") flashe, dann geht es! Es muss also irgendwie an den 
Einstellungen (Compiler, Linker) liegen....

Habe mal wie von Dieter Graef vorgeschlagen -lgcc bei den Linker-Flags 
hinzugefügt, aber das hat keine Änderung verursacht.

Auch macht es keinen Unterschied ob ich uint64_t oder int64_t 
benutze....

Bin echt ratlos. Hat noch jemand eine Idee?

[Doran S. (utzer)]

Johannes S. schrieb:
> beim gcc auf einem F407 mit gcc kompiliert wird das richtig gerechnet:
>

>     uint64_t freq = 14000;
>     uint32_t FTW = (uint32_t)((0x100000000ULL * freq) / 125000ULL);
>     printf("testvar: %lx\n", FTW);
>

> output:
> testvar: 1cac0831

Cool, wie hast Du compiliert? (Welche Compiler- und 
Linker-Einstellungen?)

[Niklas G. (erlkoenig)]

Doran S. schrieb:
> ich komme einfach nicht weiter.

Hilf dir doch selbst. Reduziere das Programm auf ein Minimum, welches 
immer noch den Fehler hat - idealerweise nur eine main()-Funktion mit 
eine paar wenigen Zeilen, ganz ohne jegliche Ansteuerung externer 
Peripherie. Du kannst ja ggf. eine LED einschalten o.ä. um zu sehen ob 
es noch läuft, auf der tatsächlichen Hardware ohne Debug-Möglichkeit.

Stelle sicher dass die Division tatsächlich zur Laufzeit durchgeführt 
wird, und nicht vom Compiler wegoptimiert. Eine Möglichkeit das zu 
tricksen wäre z.B.:

uint32_t test (uint32_t freq) __attribute__ ((noinline));
uint32_t test (uint32_t freq) {
  return (uint32_t)(((uint64_t)(0x100000000) * (uint64_t)(freq)) / ((uint64_t)(125000)));
}

int main () {
  test (1234);
}

Das Ergebnis-Programm mit Fehler spielst du dann auf ein 
STM32F103-Eval-Board, debuggst es mit einem ST-Link und gehst es Schritt 
für Schritt durch bis es abstürzt. Dieses Programm 
(Code+Kompilat/ELF-Datei) kannst du dann auch hier hochladen damit wir 
es auch ausprobieren können.

Warum steht im Code eigentlich was von STM32F100 während es aber ein 
STM32F103 sein soll? Nicht dass der Takt oder Power-Management falsch 
initialisiert wird oder so. Das kann alle möglichen kuriosen Effekte 
haben.

[hfhd (Gast)]

Doran S. schrieb:
> Bin echt ratlos. Hat noch jemand eine Idee?

Stack/heap?

die keil/iar IDEs haben ja in den einstellungen angaben für die 
Stack/heapgrößen

[Johannes S. (Gast)]

Doran S. schrieb:
> Cool, wie hast Du compiliert? (Welche Compiler- und
> Linker-Einstellungen?)

ich habe das mit Mbed gemacht, den F407 habe ich gerade hier liegen und 
die Zeilen sind da schnell reinkopiert.
Die Compileroptionen sind so gesetzt, hatte das debug Profil genutzt:
https://github.com/ARMmbed/mbed-os/blob/master/tools/profiles/debug.json
Gegenüber deinem Makefile sind hier wohl vor allem noch -WExtra wichtig 
für striktere Prüfung, mit -Og ist die Optmimierung reduziert.

Wie die Vorredner glaube ich nicht das die long long Operationen das 
Problem sind, es wird nur hier sichtbar. So Spätfolgen passieren bei 
korupptem Stack oder Querschreibern, schreiben über Arraygrenzen hinweg 
oder Zeigerfehler.
Auch die Newlib Nano kann long long rechnen, nur das printf ist da 
reduziert und kann die nicht ausgeben. Führt aber auch nicht zu 
Programmfehlern.

Evtl. mal als C++ übersetzen, das ist ja pingeliger und so Sachen wie 
impliziete Funktionsdeklarationen sind Fehler und keine Warnungen.

[Doran S. (utzer)]

Hallo,

bin nun einen Schritt weiter: Wenn ich mein Linker-Skript (STM32F100.ld) 
und meinen Startup-Code (crt0.c) durch den vom Projekt von "STM 
Apprentice" ersetze, dann geht es. Mein Fehler ist also entweder im 
Startup-Code und/oder im Linker-Skript. Kann jemand erkennen, was im 
einem Startup-Code oder Linker-Skript fehlt?

[Niklas G. (erlkoenig)]

Doran S. schrieb:
> Kann jemand erkennen, was im
> einem Startup-Code oder Linker-Skript fehlt?

Im Linkerscript fehlt vor dem "_bss_section_start", dem 
"_bss_section_end", "_data_section_start", "_data_section_end", 
"__end__", "(*.stack)" jeweils ein ".=ALIGN(4)". Wo hast du das kaputte 
Linkerscript her? Warum nimmst du nicht eins von der IDE oder aus 
STM32Cube?

Ist denn die Definition des Interrupt-Vektor im Startup-Code korrekt und 
für deinen Controller passend?

[Doran S. (utzer)]

Hallo,

also, das Problem war letztendlich das Linker-Skript.
(Und als ich das korrekte von dem Projekt von "STM
Apprentice" zusammen mit einem Startup-Code "crt0.c" verwendet hatte, 
hat es nicht funktioniert, weil ein paar Namen (von Sections) anders 
sind. Nachdem ich das korrigiert hatte, hat es funktioniert.)

Um sowas in Zukunft besser zu können, möchte ich mehr über 
Linker-Skripte lernen. Kann mir jemand Literatur oder ein Tutorial dazu 
empfehlen?

Außerdem ist mir nicht so ganz klar, was die einzelnen Sections 
bedeuten, also wozu der Prozessor diese benötigt.

Was liegt in .init? Was in .fini? Was ist das .eh_frame? .ARM.extab und 
.ARM.exidx? Wo kann man diese Dinge lernen?

Vielen Dank an alle für die vielen Tipps, die dann zur Lösung geführt 
haben.

Ein Problem bleibt: Wem schicke ich nun das Display? ;-)

[STM Apprentice (Gast)]

Doran S. schrieb:
> Ein Problem bleibt: Wem schicke ich nun das Display?

Du hast dich bei mir schon bedankt indem du geschrieben hast
wie es ausgegangen ist. Das wünschen sich alle die so einen
Thread verfolgen, und du hast es dankenswerter Weise getan.

[J. -. (Gast)]

Doran S. schrieb:
> Ein Problem bleibt: Wem schicke ich nun das Display? ;-)

Äh, mir natürlich. Was für eine seltsame Frage.

;))