gcc fuer STM32F4

Olaf Gast #2695159
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Olaf Gast #2697431
Lesenswert?
• ▲
▼ 
> 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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Olaf Gast #2699139
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. Bitte hier nur auf die ursprüngliche Frage antworten, für neue Fragen einen neuen Beitrag erstellen.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.