mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32F4 mit Code::Blocks


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: André W. (andre-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Für all diejenigen, denen die ganzen eclipse-basierten IDE-Lösungen für 
den Cortex-Mx und dem GCC nicht wirklich zusagen möchte ich hier eine 
Alternative vorstellen (in diesem Fall speziell für das 
STM32F4-Discovery-Board unter Windows - sollte aber auch ohne größere 
Probleme auch unter Linux und für andere Cortex-M Prozessoren zum laufen 
gebracht werden können):

Dazu braucht ihr:
1) Code::Blocks:
Ich verwende eine relativ aktuelle Version aus dem *SVN (#8086)* - mit 
der derzeit letzten Stable-Version wird es nicht funktionieren, da dort 
u.a. einige Funktionen im Debugger noch nicht zur Verfügung stehen.
Hier ein Link zur Detaillierten beschreibung der "Nightly-Builds": 
http://forums.codeblocks.org/index.php/topic,16560.0.html

Kurz zusammengefasst:
einfach den Inhalt dieser 3 Archive z.B. in C:\Programme\CodeBlocks\ 
entpacken:
http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2812_gcc452-TDM.7z
http://prdownload.berlios.de/codeblocks/mingwm10_gcc452-TDM.7z
http://prdownload.berlios.de/codeblocks/CB_20120707_rev8086_win32.7z
CodeBlocks kann danach einfach über eine Verknüpfung zur CodeBlocks.exe 
gestartet werden.

2) GNU Tools for ARM Embedded Processors:
Ich verwende die aktuellste Version (*4.6-2012-q2-update*) - die älteren 
Versionen haben noch einen Bug im GDB, der mit den absoluten Dateipfaden 
im Windows-Stil Probleme hat (der ":" bei C:\ wird falsch 
interpretiert), wodurch das Debugging mit CodeBlocks nicht funktioniert, 
also auf jedenfall die aktuellste Version des Compilers verwenden!
Direkter Download-Link - einfach installieren:
https://launchpad.net/gcc-arm-embedded/4.6/4.6-2012-q2-update/+download/gcc-arm-none-eabi-4_6-2012q2-20120614.exe

3) GDB-Server aus dem Atollic-Truestudio:
Nach der installation der kostenlosen Version liegt der GDB-Server in:
C:\Program Files\Atollic\ST-LINK_gdbserver\
Dieser ganze Ordner kann bei bedarf einfach kopiert werden und Atollic 
wieder deinstalliert werden.
Zur Verwendung muss nur die .bat-Datei ausgeführt werden, bevor der 
Debugger in CodeBlocks gestartet wird
Sollte der GDB-Server nicht richtig starten (als letzte Zeile der 
Ausgabe sollte stehen: "Waiting for client connect on port 61234") muss 
der ST-Link_V2_USBdriver.exe, der im gleichen Server wie der GDB-Server 
liegt, noch installiert werden.

4) Einstellungen in CodeBlocks:
Hauptsächlich muss nur der Pfad zum Compiler und Debugger eingestellt 
werden, der Rest wird durch das Projekt-File erledigt.
Dazu unter Settings->Compiler bzw. Settings->Debugger die Einstellungen 
entsprechend den angehängten Bildern vornehmen.
Am besten mit den Debugger-Einstellungen beginnen, da man sonst in den 
Compiler Einstellungen nicht gleich den richtigen Debugger auswählen 
kann.
Der executable-Path beim Debugger muss auf den arm-none-eabi-gdb.exe 
gesetzt werden (wird im Bild nicht ganz deutlich)
Die "Number of processes for parallel builds" sollte auf die Anzahl der 
CPU-Cores+1 gesetzt werden - also bei einem Dual-Core auf 3 - den Wert 
auf 1 zu lassen schadet bei der größe der meisten Projekte aber auch 
nicht..

5) Das Beispielprojekt aus dem Anhang:
Einfach irgendwo hin entpacken *(der Pfad darf KEINE Leerzeichen 
enthalten!)* - das Projekt aber noch nicht öffnen!

6) STM32F4 DSP StdPeriphLib V1.0.1:
http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/FIRMWARE/stm32f4_dsp_stdperiph_lib.zip
Direkt in das Beispiel-Projektverzeichnis Entpacken.
Nach dem Entpacken sollte die Verzeichnisstrucktur so aussehen: 
STM32F4-Test\STM32F4xx_DSP_StdPeriph_Lib_V1.0.1\...

7) Projekt über das *.cbp-File aus CodeBlocks heraus öffnen

8) Unter Project->Build Options und Project->Properties können die 
genauen Einstellungen zum compilieren festgelegt werden. In den 
Properties->Build Targets kann dann auch eingestellt werden, welche 
Dateien aus der StdPeriphLib mit compiliert werden - im 
Beispiel-Projekt, das einfach die 4 LEDs des Discovery-Board 
nacheinander einschaltet werden nur die 'rcc' und 'gpio' benötigt - mehr 
ist derzeit deshalb auch nicht aktiviert..

9) Wenn die Debug-Konfiguration compiliert wurde und der GDB-Server von 
Atollic gestartet ist kann das Programm einfach in den Flash geschrieben 
werden, indem man Debug->Start/Continue anwählt (oder F8 drückt)
Wenn in den Debugger-Optionen, wie im Angehängten Bild zu sehen, die 
Option "Do NOT run the Debugee" aktiv ist wird nach dem Flashen der 
Prozessor angehalten - das Programm läuft erts bei einem zweiten Klick 
auf Debug/Continue los!

10) Wird die Release-Configuration compiliert befindet sich nach dem 
Compilieren in  bin/Release/ ein *.bin-File, das mit dem ST-Link utility 
in den Prozessor geflasht werden kann.

Wenn alle Schritte so befolgt werden sollte man direkt zu einer 
funktionsfähigen Firmware kommen.

Das Beispielprojekt ist mit Sicherheit nicht perfekt, aber ein guter 
Ansatz für erste Versuche mit CodeBlocks.
Woran ich zum Beispiel bis jetzt gescheitert bin ist, die Firmware beim 
Debuggen im Ram des Prozessors laufen zu lassen, um nicht bei jedem 
Versuch den Flash beschreiben zu müssen.
Vorschläge zur Verbesserung der Projekt-Einstellungen - vor allem der 
Compiler-Parameter - werden gerne entgegen genommen ;)
Vielleicht hat auch jemand noch einen Tipp, wie man einfacher an den 
GDB-Server von Atollic kommen kann, ohne dass man die ganze Software 
vorher installieren muss.

Autor: erhardd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...sehr gute Arbeit!
Ich fürchte nur, wer den Eclipse-Moloch schon am Laufen hat, wird vor 
einer neuen IDE zurückschrecken.

Wenn ich mich recht erinnere, ist CODE::BLOCKS bei weitem nicht so 
umfangreich!
Ich habe CB schon lange laufen, allerdings nur als Hilfseditor für z.B. 
RIDE, der von Haus aus keine .h - files anzeigt(ist aber kein Nachteil, 
den so ist es übersichtlicher, wenn die Programme grösser sind);
Das stm32_st-link-utility kann als .zip von ST heruntergeladen werden...

Wie stellst Du beim Projekt erstellen das Device ein? (Und das passende 
Linker-file?);
Du merkst sicherlich, ich habs selbst nochnicht ausprobiert...

Autor: André W. (andre-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Device wird in den Build Options unter "Compiler Settings" und 
"Linker Settings" eingestellt, direkt über die Parameter, mit denen der 
Compiler gestartet wird. Also z.B. -mcpu=cortex-m4.
Das Linker-File ebenso über den entsprechenden Parameter. z.B. 
-T"${PROJECT_DIR}stm32_flash.ld"
Dabei muss man aber aufpassen, das in der Auswahl auf der linken Seite 
das ganze Projekt ausgewählt hat und nicht das Debug bzw. Release 
Target.

Man könnte das ganze aber auch noch etwas übersichtlicher gestalten, in 
dem man sich im Tab Custom-Variables eigene Variablen anlegt, die dann 
an den entsprechenden Stellen eingesetzt werden. (so hätte man eine 
Zentrale Anlaufstelle für die meisten Compiler-Optionen..)

Autor: erhardd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...die Idee ist gut!
Ich probiers aus, wenn ich die Zeit finde.
(Ätze grad ein neues Aufsteckboard WLAN/LAN für STM32F417)
Danke...

Autor: Markus M. (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe den Thread mal reingenommen in den Artikel STM32 unter 
"Programmierung".

Autor: EMIDE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.emide.org/

* für ARM
* basiert auf Code::Blocks
* Plugin für J-Link gdbserver

Autor: Alexander B. (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Hab die emIDE gerade mal ausprobiert.
Wenn ich ein neues Projekt erstellen will zeigt er mir keinen Wizard an 
ich komme da also nicht weiter. Viel weiter habe ich dann garnicht 
getestet, weil mein Eclipse läuft. Aber interessant finde ichs schon.

Wie ist das mit Cpp bei Code::Blocks?

MfG

Tec

Autor: André W. (andre-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Müller schrieb:
> Ich habe den Thread mal reingenommen in den Artikel STM32 unter
> "Programmierung".

Danke, wollte ich bei Gelegenheit auch machen..


EMMIDE schrieb:
> http://www.emide.org/
>
> * für ARM
> * basiert auf Code::Blocks
> * Plugin für J-Link gdbserver

Ich habe mir das ganze gerade einmal kurz angeschaut, leider wäre das 
für mich keine Alternative, da offensichtlich wirklich nur der J-Link 
unterstützt wird und keine anderen Debugger, wie z.B. der ST-Link auf 
den Discovery-Boards. Somit ist wieder an spezielle Hardware gebunden.
Soweit ich das erkennen kann fehlt jetzt sogar die Möglichkeit einen 
beliebigen GDB-Server zu verwenden.
(Ich gehe einmal davon aus, dass Du der Verantwortliche von emIDE bist, 
da es ja anscheinend noch nicht so weit verbreitet ist..)
Mir ist aufgefallen, dass es keinen Quellcode mit den Änderungen zum 
ursprünglichen CodeBlocks Source-Code gibt. Ich bin zwar nicht wirklich 
Experte auf dem Gebiet, aber soweit mir bekannt ist lässt sich das so 
mit der GPL nicht vereinbaren..
Vor allem, da in emIDE einige interessante Bugfixes existieren, die bei 
CodeBlocks noch nicht verfügbar sind:

> "Double execution of forst additional GDB command, handle lines starting with # 
in additional GDB commands as comment"
Ich hatte schon einmal vermutet, dass CodeBlocks den "load"-Command, der 
in meinem Beispiel-Projekt als erster Command im GDB ausgeführt wird, 
zwei mal an den GDB sendet..

> "Added 'Reset target' to the debugger."
Den 'Reset Target'-Button gibt es in CodeBlocks nicht - ist allerdings 
auch kein großes Problem, da man ein "monitor reset" über das 
Debugger-Window auch direkt an den GDB absetzen kann. Es würde aber 
etwas Zeit sparen, wenn man nur einen Button anklicken müsste.

Was emIDE aber auch noch fehlt, ist eine Trennung zwischen Debugger 
starten und Programmspeicher beschreiben - ich habe zumindest öfter den 
Fall, dass ich zwar noch einmal Debuggen will, sich aber an dem 
Programmcode nichts geändert hat. Somit wäre ein neues beschreiben des 
Flash zum einen unnötige Zeit und zum anderen werden Write-Cycles des 
Flash verschwendet.

------------------------------------------------------------
Noch ein paar Tips zum Beispiel Projekt aus dem ersten Post:
Man könnte unter "Project->Properties->Debugger->Debug->Additional GDB 
Commands" den "load"-Befehl einfach herausnehmen, dann wird der Flash 
beim starten des Debuggers nicht neu beschrieben.
Das Flashen könnte dann bei aktivem Debugger durch einen manuell 
abgesetzten Load-Command gestartet werden.
Oder man legt sich alternativ unter "Build Targets" weitere Targets an - 
wie z.B. "Debug" und "Flash+Debug", die dann entsprechend den load 
ausführen oder nicht.
Auch interessant wäre hier ein Target "Debug in RAM", bei dem der 
komplette Code in den Ram geladen wird. Allerdings habe ich mich damit 
noch nicht genug beschäftigt und mir fehlen hier noch ein paar Infos, 
was man dazu noch alles braucht.
Vermutlich müsste dazu das Linker-File geändert werden und in den Flash 
an den Reset- und Interrupt-Vektoren ein Sprung zu den entsprechenden 
Stellen im RAM gesetzt werden.
Wenn jemand Infos dazu hat - gerne her damit ;)

Tec Nologic schrieb:
> Moin,
>
> Hab die emIDE gerade mal ausprobiert.
> Wenn ich ein neues Projekt erstellen will zeigt er mir keinen Wizard an
> ich komme da also nicht weiter. Viel weiter habe ich dann garnicht
> getestet, weil mein Eclipse läuft. Aber interessant finde ichs schon.
>
> Wie ist das mit Cpp bei Code::Blocks?
>
> MfG
>
> Tec

Das mit dem Wizard ist mir auch direkt nach dem Starten aufgefallen. Ein 
neues Projekt anzulegen scheint unmöglich zu sein.
Cpp ist bei CodeBlocks kein Problem.

Autor: EMIDE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich bin nicht der Entwickler der IDE. :-)

Bin nur durch Zufall drüber gestolpert:
http://www.segger.com/jlink-ide-integration.html

Da ich beruflich mit IAR und dem J-Link arbeite, bin ich ein großer Fan 
von diesem Duo. Die Qualität der Software rund um den J-Link finde ich 
prima hinsichtlich Stabilität.

Daher würde ich den gerne auch privat einsetzen (J-Link EDU für ca. 
50EUR).
Nur leider ist mir die EWB von IAR zu teuer, um sie privat kaufen. Die 
Kickstart-Version reicht leider nicht mehr aus.

Daher suche ich jetzt nach einer freien Alternative, die den J-Link 
benutzen kann. Generell bin ich auch nicht so der Eclipse-Fan.
Da kam emIDE gerade gelegen.

Leider habe ich auch noch nicht herausgefunden, wie man ein Projekt 
anlegt.

Autor: André W. (andre-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann probiere doch erst einaml CodeBlocks ohne die Modifikationen von 
emIDE - da es ja soweit ich gesehen habe einen GDB-Server für den J-Link 
gibt sollte es kein großartiges Problem sein das Beispiel-Projekt auf 
den J-Link GDB-Server einzustellen.
Im Prinzip müsste man nur unter Project/Debugger den Port anpassen und 
ggf. noch bei den additional commands kleine Anpassungen machen - der 
Rest sollte gleich bleiben können. Und man müsste halt im gegensatz zu 
emIDE den GDB-Server von Hand starten..
Für andere Prozessoren braucht man ggf. noch entsprechende Linker und 
Starter-Files - die sollten sich aber auch finden lassen.

Ich bin gerade dabei mir ein neues Projekt Template zu bauen, mit den 
Erkenntnissen der letzten Tage.. mal sehen was dabei raus kommt.

Autor: André W. (andre-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang gibt es jetzt das Ergebnis des neuen Templates! (Anweisungen 
zur Verwendung in der README.txt)

jetzt sind unter Custom Variables die wichtigsten Einstellungen für den 
Prozessor zusammengefasst und es gibt 3 Targts:
Flash+Debug:
Dieses Target startet den Debugger und beschreibt sofort den Flash mit 
dem aktuell compilierten File.

Debug:
Wenn man den Debugger mit diesem Target startet wird nur der GDB 
gestartet - der Flash aber nicht beschrieben.

Release:
erzeugt ein ${PROJECT_NAME}.bin-File, dass mit dem ST-Link Utility auf 
den Prozessor geladen werden kann.

Autor: EMIDE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich habe das mit CB und einem J-Link EDU jetzt soweit laufen.

Kannst Du mir erklären, was das Ändern des Linker-Skripts bewirkt?
Stichwort: " _exit = .;"

Ich kann meinen Startup-Code nämlich ohne Probleme debuggen.
Allerdings lande ich immer im Hard Fault Handler sobald ich auf "BL 
__libc_init_array" komme.

Ich muss dazu sagen, dass ich einen STM32L152VB benutze. Ich hatte mir 
ein Projekt von Atollic Truestudio Lite generieren lassen und das 
Linker-Skript benutzt.

Autor: EMIDE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok. Das Problem mit __libc_init_array() hat sich erledigt.
Es ist bei Dir ja auch aus kommentiert.

Da kein C++ mit statischen Konstruktoren vorhanden ist, wird das wohl 
nicht benötigt. Siehe dazu Punkt 22:
http://eetimes.com/design/embedded/4026075/Building-Bare-Metal-ARM-Systems-with-GNU-Part-2

Könntest Du das mit dem Linker-Skript trotzdem noch erläutern? Danke!

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
erhardd schrieb:
> ...die Idee ist gut!
> Ich probiers aus, wenn ich die Zeit finde.
> (Ätze grad ein neues Aufsteckboard WLAN/LAN für STM32F417)
> Danke...

Was für ein WLAN-Modul verwendest du denn?

Autor: erhardd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beitrag "stm32f4 Bord im LAN"
@Tobi (Gast)
...dieses wird nur mit einem DP83848 PHY gekoppelt...

Autor: André W. (andre-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EMIDE schrieb:
> Hi!
>
> Ich habe das mit CB und einem J-Link EDU jetzt soweit laufen.
>
> Kannst Du mir erklären, was das Ändern des Linker-Skripts bewirkt?
> Stichwort: " _exit = .;"
>
> Ich kann meinen Startup-Code nämlich ohne Probleme debuggen.
> Allerdings lande ich immer im Hard Fault Handler sobald ich auf "BL
> __libc_init_array" komme.
>
> Ich muss dazu sagen, dass ich einen STM32L152VB benutze. Ich hatte mir
> ein Projekt von Atollic Truestudio Lite generieren lassen und das
> Linker-Skript benutzt.

Hi,

mit dem Linker-Script bin ich auch noch nicht so richtig Fit - aber hier 
mal ein Versuch zur Erklärung (ohne Garantie auf Richtigkeit!):

wenn der Eintrag im Linkserscript fehlt bekomme ich beim linken folgende 
Fehlermeldung:
arm-none-eabi-g++.exe
    -o bin\Debug\TRIP_STM32_Graph.elf
    obj\Debug\STM32F4xx_DSP_StdPeriph_Lib_V1.0.1\Libraries\CMSIS\Device\ST\STM32F4xx\Source\Templates\system_stm32f4xx.c.o
    obj\Debug\STM32F4xx_DSP_StdPeriph_Lib_V1.0.1\Libraries\STM32F4xx_StdPeriph_Driver\src\stm32f4xx_gpio.c.o
    obj\Debug\STM32F4xx_DSP_StdPeriph_Lib_V1.0.1\Libraries\STM32F4xx_StdPeriph_Driver\src\stm32f4xx_rcc.c.o
    obj\Debug\TRIP_STM32_Graph\main.c.o
    obj\Debug\STM32F4xx_DSP_StdPeriph_Lib_V1.0.1\Libraries\CMSIS\Device\ST\STM32F4xx\Source\Templates\TrueSTUDIO\startup_stm32f4xx.s.o
    -mthumb
    -Wall
    -mlittle-endian
    -T"C:\Software\TRIP_STM32_Graph\..\STM32F4xx_DSP_StdPeriph_Lib_V1.0.1\Project\STM32F4xx_StdPeriph_Templates\TrueSTUDIO\STM324xG_EVAL\stm32_flash.ld"
    -mcpu=cortex-m4
    -mfloat-abi=hard
    -mfpu=fpv4-sp-d16
    -g

c:/program files (x86)/gnu tools arm embedded/4.6 2012q2/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7e-m/fpu\libg.a(lib_a-exit.o): In function `exit':
exit.c:(.text.exit+0x16): undefined reference to `_exit'

Was vermutlich daran liegt, dass der Linker nicht weis an welche Stelle 
er diese Section schreiben soll.
Die Zeile im Linker-Script teilt ihm das dann mit, das die Funktion an 
das Ende des Flash kommt. (Die Problemlösung hatte ich durch googlen 
gefunden - aber den Link nicht mehr parat..)

Wozu er überhaupt die exit funktion mit linken will ist mir allerdings 
ein Rätsel, da auf einem µC die Main in eine Endlos-Schleife läuft und 
nie ein Exit benötigt wird.

Vermutlich wurde deswegen die Exit-Funktion in der Atollic-Toolchain 
(von der ja eigentlich das Linkerscript stammt) weg optimiert und auch 
kein Eintrag im Linkerscript dazu erstellt,
während sie in den GNU Tools for ARM Embedded Processors noch mit 
vorhanden ist..

Gruß,
André

Autor: EMIDE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@andre-w

Strange. Ich habe das Linker-Skript so gelassen, wie es dem Atollic 
herauskommt. Bei mir läuft der Compiler durch.

Wie genau läuft das hier jetzt eigentlich mit der libc?
Ich möchte natürlich auch ein paar Ausgaben mit printf() erzeugen.

Beim Atollic kann man dazu ja die Funktion _write() schreiben, die dann 
angeblich vom eingebauten printf() benutzt werden kann.

Zum Beispiel so:
int _write(int file, char *ptr, int len)
{
  /* Implement your write code here, this is used by puts and printf for example */
  int i=0;
  for(i=0 ; i<len ; i++)
    ITM_SendChar((*ptr++));
  return len;
}

Gibt es so einen Mechanismus auch bei den ARM GNU Tools?
Wenn ich stdio.h einbinde und printf() aufrufe, dann gibt es sofort 
einen Hard Fault.

Autor: EMIDE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also irgendetwas scheint da noch faul zu sein.
Die Kombination aus Startup-Code und Linker-Skript scheint nicht so ganz 
zu passen. Zumindestens nicht, wenn man die libc (newlibc) der GNU ARM 
Toolchain benutzen möchte, die ja dabei ist.

Muss die libc nicht erst im Startup-Code initialisiert werden? Einsprung 
_start zum Beispiel?
In der README.TXT der Toolchain steht sowas zumindestens im 
Startup-Code.
Wenn ich das aber einbaue, dann lande ich wieder im Hard Fault Handler.

Ist die Atollic Toolchain denn SO anders? Die benutzen doch auch die 
newlibc.

Autor: EMIDE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Skript passend zum STM32L152VB:
/* Entry Point */
ENTRY(Reset_Handler)

/* Highest address of the user mode stack */
_estack = 0x20004000;    /* end of 16K RAM */

/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0;      /* required amount of heap  */
_Min_Stack_Size = 0x80; /* required amount of stack */

/* Specify the memory areas */
MEMORY
{
  FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 128K
  RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 16K
  MEMORY_B1 (rx)  : ORIGIN = 0x60000000, LENGTH = 0K
}

/* Define output sections */
SECTIONS
{
  /* The startup code goes first into FLASH */
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >FLASH

  /* The program code and other data goes into FLASH */
  .text :
  {
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.text*)          /* .text* sections (code) */
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    *(.glue_7)         /* glue arm to thumb code */
    *(.glue_7t)        /* glue thumb to arm code */
    *(.eh_frame)

    KEEP (*(.init))
    KEEP (*(.fini))

    . = ALIGN(4);
    _etext = .;        /* define a global symbols at end of code */
  } >FLASH


   .ARM.extab   : { *(.ARM.extab* .gnu.linkonce.armextab.*) } >FLASH
    .ARM : {
    __exidx_start = .;
      *(.ARM.exidx*)
      __exidx_end = .;
    } >FLASH

  .preinit_array     :
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array*))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  } >FLASH
  .init_array :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array*))
    PROVIDE_HIDDEN (__init_array_end = .);
  } >FLASH
  .fini_array :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array*))
    PROVIDE_HIDDEN (__fini_array_end = .);
  } >FLASH

  /* used by the startup to initialize data */
  _sidata = LOADADDR(.data);

  /* Initialized data sections goes into RAM, load LMA copy after code */
  .data :
  {
    . = ALIGN(4);
    _sdata = .;        /* create a global symbol at data start */
    *(.data)           /* .data sections */
    *(.data*)          /* .data* sections */

    . = ALIGN(4);
    _edata = .;        /* define a global symbol at data end */
  } >RAM AT> FLASH

  /* Uninitialized data section */
  . = ALIGN(4);
  .bss :
  {
    /* This is used by the startup in order to initialize the .bss secion */
    _sbss = .;         /* define a global symbol at bss start */
    __bss_start__ = _sbss;
    *(.bss)
    *(.bss*)
    *(COMMON)

    . = ALIGN(4);
    _ebss = .;         /* define a global symbol at bss end */
    __bss_end__ = _ebss;
  } >RAM

  /* User_heap_stack section, used to check that there is enough RAM left */
  ._user_heap_stack :
  {
    . = ALIGN(4);
    PROVIDE ( end = . );
    PROVIDE ( _end = . );
    . = . + _Min_Heap_Size;
    . = . + _Min_Stack_Size;
    . = ALIGN(4);
  } >RAM

  /* MEMORY_bank1 section, code must be located here explicitly            */
  /* Example: extern int foo(void) __attribute__ ((section (".mb1text"))); */
  .memory_b1_text :
  {
    *(.mb1text)        /* .mb1text sections (code) */
    *(.mb1text*)       /* .mb1text* sections (code)  */
    *(.mb1rodata)      /* read-only data (constants) */
    *(.mb1rodata*)
  } >MEMORY_B1

  /* Remove information from the standard libraries */
  /DISCARD/ :
  {
    libc.a ( * )
    libm.a ( * )
    libgcc.a ( * )
  }

  .ARM.attributes 0 : { *(.ARM.attributes) }
}

Autor: EMIDE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke, dass mein Problem evtl. hier zu suchen ist:
Beitrag "STM32F4 C++ springt bei __libc_init_array in den HardFault"

Autor: EMIDE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieder etwas gelernt.

Die newlibc benutzt verschiedene Implementierungen, die für die 
jeweilige Architektur optimiert sind. Stichwort: multilibs

Welche lib nun ausgewäht wird, kann man so überprüfen:
arm-none-eabi-gcc.exe -print-multi-directory -mcpu=cortex-m3 -mthumb
armv7-m

Hier wird also "armv7-m" ausgespuckt. Dort befindet sich nun auch die 
richtige libc, die nur aus dem Thumb-Befehlssatz besteht. Der Cortex-M3 
unterstützt ja nur diesen.

Man muss also in CB noch unter den Linker Settings folgende Schalter 
einfügen: -mcpu=cortex-m3 -mthumb
Dann benutzt der Linker auch die richtige libc und es gibt keinen Hard 
Fault mehr, weil die CPU in den ARM Modus springen sollte.

Autor: EMIDE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es für CB evtl. ein Plugin mit dem eine bessere Disassembly-Ansicht 
bekommt? Das was da aktuell geboten wird, ist ja recht spatanisch.
Derzeit bekommt man nur ein wenig Assembler der aktuellen C-Source Zeile 
angezeigt. Scrollen ist nicht möglich.

Autor: Johann H. (joe-c)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuche schon seit einiger Zeit C::B als IDE für den STM32F4 
einzustellen, aber es klappt irgendwie nicht richtig.

Aktuell habe ich eine Portable Variante von CodeBblocks 12.11 und den 
GNU (Link aus dem ersten Beitrag) in Verwendung.
Der oben mitgelieferte Projektodner (STM32F4-Template2.zip) ist eine 
abgewandelte Variante von André W. (Beitrag #2768278)

Bulid/Rebuild laufen in Debug und Release ohne Warnungen und Fehler 
durch. Die *.bin wird auch erstellt und lässt sich mit dem ST-Link 
Untility öffnen.
Das Problem ist allerdings, die Sartadresse ist immer 0x00000000, 
weshalb ich auch folgende Fehlermeldung bekomme:
STM32 ST-LINK CLI v1.4.0
STM32 ST-LINK Command Line Interface
Connected via SWD.
Device ID:0x411
Device flash Size : 1024 Kbytes
Device family :STM32F4xx
Flash Programming:
File : output\Release\exe\Blinky_STM3240G.bin
Address : 0x00000000
[0x00000000]:Invalid address!
MCU Reset.
Application started.

Zusätzlich hab ich die http://www.emide.org/ ausprobiert. Dort hab ich 
ein Testprojekt erstellt und bei postbuild folgende Erweiterung 
eingegeben:
arm-none-eabi-objcopy -O binary ${PROJEKT_DIR}output\Release\exe\${PROJECT_NAME}.elf ${PROJEKT_DIR}output\Release\exe\${PROJECT_NAME}.bin
arm-none-eabi-size --format=berkeley ${PROJEKT_DIR}output\Release\exe\${PROJECT_NAME}.elf
C:\Users\Talentfrei\Desktop\CodeBlocks-12P_big\tool\ST-LINK_gdbserver\ST-LINK_CLI.exe -c SWD -P "${PROJEKT_DIR}output\Release\exe\${PROJECT_NAME}.bin" -Rst -Run

Interessanterweise ist die Wirkung fast dieselbe. Build ohne Fehler und 
Warnungen und am Ende ist eine BIN Datei da. Aber auch hier ist die 
Startadresse wieder 0x00000000.

Ich weiss nicht was ich falsch mache. Hab einen Fehler im Linkerscript 
vermutet und versucht hier eine Lösung zu finden 
http://www.bravegnu.org/gnu-eprog/c-startup.html
wurde aber nicht fündig.

Kann mir jemand sagen, was ich falsch mache und wie es richtig wäre?

MFG

Autor: Johann H. (joe-c)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
...irgendwie sind die Anhänge abhanden gekommen... neuer Versuch.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
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.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.