STM32F10X_CL Linker script

[Flo (Gast)]

In meinem Projekt setze ich den STM32F105RB ein.
Also Connectivity Line mit 128k Flash, 32k Ram.

Als Basis benutze ich ein Projekt von M. Thomas
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#chanfat_stm32
Läuft so auch erstmal alles wunderbar.
Aber ich weiß, dass das Linker script nur für den STM32F103 mit weniger 
Periperie ist.
Wenn ich im Makefile
CDEFS = -DSTM32F10X_MD
in
CDEFS = -DSTM32F10X_CL
ändere, spuckt der Usart nur noch Müll aus.

Ich würde jetzt gerne das Linker script und was sonst noch notwendig ist 
anpassen, damit alles korrekt läuft.

Im STM32F10x_128k_20k_flash.ld habe ich die Zeile
RAM      (RWX) : ORIGIN = 0x20000000+0, LENGTH = 32K-0
in
RAM      (RWX) : ORIGIN = 0x20000000+0, LENGTH = 20K-0
geändert. Reicht das?

In startup_stm32f10x_md_mthomas.c werde ich alle isr (isr_vectorsram) 
ergänzen müssen, die der 105 mehr hat.

Sonst noch etwas?

Ich bin mit den ARMs noch ziemlicher Anfänger (vorher AVR) und die ganze 
Linkergeschichte muss noch etwas sacken.
Bin aber lernwillig :)

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Stack Pointer richtig gesetzt?

Irgendwo müsste "_estack" definiert sein. Der Stackpointer wird bei 
"g_pfnVectors:" automatisch initialisiert.

In der "stm32f10x.h" muss auch noch der Device-Typ angepasst werden

[Flo (Gast)]

Stack pointer sollte passen, da Martin das alles sehr schön über Makros 
gemacht hat.
_estack = ORIGIN(RAM)+LENGTH(RAM);

Nach meinem Verständnis muss in der "stm32f10x.h" nichts angepasst 
werden, da die zur ST lib gehört.
Alle Anpassungen da drin werden über die defines aus der makefile 
gemacht.
Ich benutze jetzt die V3.2.0 der ST Lib und nun läuft Usart.
Vermutlich hat die V3.1.2 einen Bug beim PLL initialisieren.

Jetzt zickt noch der CAN interrupt, aber das ist auch nur eine Frage der 
Zeit :)

[Flo (Gast)]

Hm, ist nicht der Interrupt, sondern der CAN läuft mit 1/3 der 
Geschwindigkeit, wie er sollte.
Also ca. 12Mhz statt 36Mhz.

Das gleiche Phänomen hatte ich vorher mit Usart unter V3.1.2.
Ein Bug in der PLL Init sollte es ja wohl nicht sein?

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Ich habe bei mir die "stm32f10x.h" angepasst, damit Eclipse die richtige 
Codevervollständigung hat.

Ich nutze die von ST gelieferten *.s Dateien nicht weil ich einen 
Bootloader drin habe. Deshalb würde die Interrupts nicht mehr tun.
Ich hab mit da was eigenes gestrickt.
In jedem Fall musste ich die Variable "SystemCoreClock" auch von Hand 
mit der richtigen Zahl beschreiben, denn ich initialisieren die Clocks 
auch selbst, so wie in der FW-Lib V2.x. Aktuell nutze ich auch die 
FW-Lib 3.2.0 und damit funktioniert CAN und USART prinzipiell richtig.

[Flo (Gast)]

Hm, ok.
Ich musste die "stm32f10x.h" jetzt auch anpassen, weil die PLL beim 105 
anders initialisiert wird als beim 103.
Kein direkter Bug, aber auf jeden Fall unschön. Der Code sollte ja durch 
die Lib eigentlich sehr leicht portierbar sein.
Bin gerade noch dabei, den Sinn davon zu verstehen.

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Irgendwo müsste man im User-Code Bereich dieses Define setzen können, 
aber die "stm32f10x.h" kann natürlich kein User-Code-Define einbinden.

Die Lösung wäre schlichtweg man hätte eine kleine Header-Datei die 
Konfigurationen/Defines beinhaltet und von der "stm32f10x.h" eingebunden 
ist. Denn in der "stm32f10x.h" rum zu doktorn ist eigentlich tötlich.
Einen Kompiller/Linker Schalter zu verwenden ist irgendwie doof, denn 
Eclipse blendet die nicht aktiven Defines (#ifdef) im Code aus, damit 
hat man viel mehr überblick.

Unschön finde ich auch wo die Variable "SystemCoreClock" initialisiert 
wird, denn die wird in der gesammten FW-LIB verwendet.

[900ss (900ss)]

Markus Müller schrieb:
> denn
> Eclipse blendet die nicht aktiven Defines (#ifdef) im Code aus, damit
> hat man viel mehr überblick.

Das kannst du abschalten in den Preferences:
Window->Preferences->C/C++->Editor->Folding->Enable Folding of 
Preprocessor branches.

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Will ich aber nicht ;)

[900ss (900ss)]

Markus Müller schrieb:
> Will ich aber nicht ;)

Uppps... ja nach einem Beschleuniger in Form eines koffeinhaltigen 
Getränkes verstehe ich dein Posting oben auch richtig. Abschalten ist 
doof ;-)