gcc fuer STM32F4

[Olaf (Gast)]

Ich bin gerade dabei meine diversen Crosscompiler auf einen aktuellen 
Stand zu bringen. (aechz) In dem Zusammenhang wollte ich auch mal einen 
Compiler fuer das Cortex/AVR Zeugs erzeugen. Leider macht der noch 
Aerger.

Stand:
Ich kann problemlos meinen Code mit gcc4.7.0 uebersetzen und mit 
gdb/st-util in den 32F407 laden. Aber bei der Ausfuehrung scheint das 
Programm wild rumzuspringen.

Ausschnitt aus stm32_flash.ld:
[..]
/* Entry Point */
ENTRY(Reset_Handler)
[..]

Aus meinem mapfile:
[..]
*(.text*)
 fill         0x0800038c        0x4 00
 .text.Reset_Handler
                0x08000390       0x50 startup_stm32f4xx.o
                0x08000390                Reset_Handler
[..]


cross-arm-objdump -f start.elf
start.elf:     file format elf32-littlearm
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x08000391

Mich erstaunt etwas das die start addresse nicht dem mapfile entspricht 
und auf einer ungeraden Adresse liegt. Soll das so? Kann vielleicht mal 
jemand den objdump mit seinem Programm ausfuehren?

Oh..und wo wir gerade so nett plaudern. Jedesmal wenn ich den gdb 
verlasse wird auch st-util beendet und ich muss es neu starten. Kann man 
das verhindern?

Olaf

[Christian G. (christian_g83)]

Olaf schrieb:

> Mich erstaunt etwas das die start addresse nicht dem mapfile entspricht
> und auf einer ungeraden Adresse liegt. Soll das so?

Ja. Wenn das letzte Bit gesetzt ist, wird die CPU in den Thumb-Modus 
geschaltet.

Christian

[huegene (Gast)]

Openocd in der noch dev-0.6.0 version bietet deutlich besseren support 
für die discovery boards

[Olaf (Gast)]

> Openocd in der noch dev-0.6.0 version bietet deutlich besseren support
> für die discovery boards

Ich wuesste nicht was ich mehr an support als einen gut laufenden gdb 
braeuchte und das scheint im Prinzip der Fall zu sein. Lediglich mit dem 
starten des Programms stimmt irgendetwas nicht.

Olaf

[Olaf (Gast)]

Ich habe gerade herausgefunden warum es bei mir nicht funktioniert. Mit 
folgender Aenderung in meinem Linkerscript komme ich zu einem laufendem 
Programm:

/* Specify the memory areas */
MEMORY
{
/*  FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 1024K
  RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 112K
  MEMORY_B1 (rx)  : ORIGIN = 0x60000000, LENGTH = 0K
*/
  FLASH (rx)      : ORIGIN = 0x20000000, LENGTH = 64K
  RAM (xrw)       : ORIGIN = 0x20010000, LENGTH = 48K
  MEMORY_B1 (rx)  : ORIGIN = 0x60000000, LENGTH = 0K
}

Mit anderen Worten, im Ram laeuft alles. Und wenn ich mal mit dem gdb 
den Rominhalt mit meinem erzeugten Code vergleiche dann wird auch klar 
warum das so ist. Wenn ich Code fuer Flashrom erzeuge wird der dort 
vorhandene Inhalt nicht ueberschrieben.
Jetzt muss aber der gdb/st-link ja fuer die Flashbereiche irgendwie eine 
Sonderbehandlung veranlassen da dort ja das Programm anders 
reingeschrieben wird als in das Ram. Kann mir mal einer erklaeren wo und 
wie das geschieht? Ich vermute mal das der bei mir glaubt ich haette 
ueberall Ram.

Olaf

[olaf (Gast)]

Okay, hat sich erledigt. st-util kann garnicht flashen, dafuer ist 
st-flash zustaendig....

olaf