STM32 FreeRTOS Projekt (Makefile - GCC)

[Oliver J. (skriptkiddy)]

Im Anhang befindet sich ein funktionierendes Beispielprojekt für 
FreeRTOS auf dem STM32F103. Als Platform habe ich das ET-STM32F103 Board 
verwendet. Das Programm lässt LEDs blinken und schreibt Daten über den 
USART1 heraus. Nichts spektakuläres, aber immerhin eine 
Ausgangsposition. ;)

Anleitung:
----------
+ Die Variable "CROSS_COMPILE" im Makefile an eure Toolchain anpassen
  (z.B. die arm-none-eabi Toolchain von Codesourcery)

+ make eingeben

+ im Ordner "output" liegt bei Erfolg dann das Kompilat


Gruß Oliver

[Entwickler (Gast)]

Hallo Oliver,

vielen Dank für das Beispiel. Das Beispiel könnte man ja auch für den 
STM32F207 anpassen.

Das generierte ELF File könnte man dies auch für den IAR Debugger 
verwenden ?

[Oliver J. (skriptkiddy)]

Entwickler schrieb:
> Das generierte ELF File könnte man dies auch für den IAR Debugger
> verwenden ?

Kann ich nicht sagen, weil ich IAREW nicht verwende.

Gruß Oliver

[Entwickler (Gast)]

Hallo Oliver,

mit welchen Freewaretool tust du dann debuggen ?

[Oliver J. (skriptkiddy)]

Entwickler schrieb:
> mit welchen Freewaretool tust du dann debuggen ?

openocd + gdb + eclipse

Gruß Oliver

[Pappnase (Gast)]

um Himmels Gottes Willen...

#define RCC_APB2ENR  (*((volatile unsigned long*)(0x40021000 + 0x018)))

gibt's da nix schöneres in den STM's Libs?

SCNR

trotz alledem ein schönes Projekt, werde ich demnächst mal damit 
rumspielen müssen.

mfg

[Entwickler (Gast)]

Ja und welche Hardware zum debuggen verwendest du dafür ?
Kann ich den IAR Debugger benutzen ?

[LTC1043 (Gast)]

Entwickler schrieb:
> Ja und welche Hardware zum debuggen verwendest du dafür ?
> Kann ich den IAR Debugger benutzen ?

Schau mal in das file stm32_freertos_blank/openocd/openocd.cfg

[Oliver J. (skriptkiddy)]

Entwickler schrieb:
> Kann ich den IAR Debugger benutzen ?
Was für einen Debugger hast du denn? Einen J-Link?

Dann sollte das mit folgender Openocd config funktionieren:

#daemon configuration
telnet_port 4444
gdb_port 4242

#interface
interface jlink

source [find target/stm32.cfg]

Segger bietet auch einen gdbserver für jlink an. Mit dem kann man sogar 
über den gdb das Target flashen.


Gruß Oliver

[Oliver J. (skriptkiddy)]

Pappnase schrieb:
> gibt's da nix schöneres in den STM's Libs?

Ja die Standard Periphal Library bietet da sehr schöne Möglichkeiten. 
Hab ich doch auch genutzt, wenn mich nicht alles täuscht. Das define ist 
wenn man es genau betrachtet toter Code. Die Deklaration von ClkInit und 
das define von SLEEP auch.

Gruß Oliver

[Christoph a. (chrichri)]

Servus ...

ich bekomme einen Linker fehler : cannot find -lgcc_s
Verwende Ubuntu mit CodeSourceryLite
Ich habe versucht manuell mit -L/... die Library einzubinden (bin mal 
alle pfade durchgegangen in denen ich libgcc_*.*) finden konnte aber 
ohne Erfolg.

Bin leider noch etwas wackelig auf den Füßen was dies Untiefen betrifft 
...

Gruß
Christoph


/usr/local/share/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none- 
linux-gnueabi/4.5.2/../../../../arm-none-linux-gnueabi/bin/ld:  cannot 
find -lgcc_s
/usr/local/share/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none- 
linux-gnueabi/4.5.2/../../../../arm-none-linux-gnueabi/bin/ld:  cannot 
find -lgcc_s

[Oliver J. (skriptkiddy)]

Christoph abc schrieb:
> ich bekomme einen Linker fehler : cannot find -lgcc_s

Versuch mal folgende LD_FLAGS:

LDFLAGS  = --gc-sections,-T$(LDSCRIPT),-no-startup

Gruß Oliver

[Christoph a. (chrichri)]

nö nützt nichts. Auch nicht so wild ...

compilieren kann ich und mit stlink und gdb flashen und "debuggen" (ich 
komm mit gdb aber nicht zurecht).

Allerdings mach ich das auch unter MacOS mit der summon arm toolchain 
und auch nur fertige Beispiel Makefile-Projekte (z.B. die 
Stlink-Examples). Und eigentich auch für den F4. Selber das mal in eine 
IDE wie Eclipse zu bringen sodass es alles läuft, und am Ende dann noch 
ein eigenes Projekt erstellen, davon träume ich noch. Diese ganze STM32 
Geschichte entwickelt sich langsam zu einem Frustpaket (weil ich nicht 
unter Win programmieren will, bzw. keinen Windows Rechner habe).

[Oliver J. (helmo2004)]

Christoph abc schrieb:
> nö nützt nichts. Auch nicht so wild ...

Ich Arbeite mit der arm-none-eabi-Toolchain 2011.03 von Codesourcery 
unter Ubuntu ohne Probleme. Zeig mal dein Makefile.

Gruß Oliver

[Oliver J. (skriptkiddy)]

Huch falscher Account.

[Christoph a. (chrichri)]

Hi
ich verwende dein Makefile unveändert aus dem Zip-Archiv.


Ich habe jetzt nochmal ganz von Vorne angefangen und Ubuntu neu 
installiert. Ich kann jetzt mit Eclipse + CodeSourcery + St-link 
arbeiten. :-) Soweit war ich noch auch noch nie...



jetzt habe ich einen anderen Fehler mit deinem Projekt:

/home/christoph/CodeSourcery/arm-2011.09/bin/../lib/gcc/arm-none-eabi/4. 
6.1/../../../../arm-none-eabi/lib/thumb2/libc.a(lib_a-sbrkr.o):  In 
function `_sbrk_r':
sbrkr.c:(.text+0x12): undefined reference to `_sbrk'
collect2: ld returned 1 exit status
make: *** [output/main.elf] Error 1

[Oliver J. (skriptkiddy)]

Christoph abc schrieb:
> sbrkr.c:(.text+0x12): undefined reference to `_sbrk'

Ohne sprintf sollte es bauen. Sorry. Ich werde noch einmal ein neues 
Paket schnüren, welches auch auf Anhieb funktioniert.

Gruß Oliver

[Oliver J. (skriptkiddy)]

Wie versprochen hier die überarbeitete Variante.

Gruß Oliver

[Christoph a. (chrichri)]

Super :-)

wenn man mal davon absieht:

/tmp/ccxttmIa.s: Assembler messages:
/tmp/ccxttmIa.s:512: Error: registers may not be the same -- `strexb 
r0,r0,[r1]'
/tmp/ccxttmIa.s:537: Error: registers may not be the same -- `strexh 
r0,r0,[r1]'
make: *** [src/fw_lib/core_cm3.o] Error 1


Google hatte auch schnell eine Lösung
https://github.com/texane/stlink/issues/65

Damit geht es dann auch.

Nur wieso funktioniert es denn bei dir?


Auf das Board habe ich es noch nicht überspielt. Mal schauen wann ich 
dazu komme.

Gruß
Christoph

[Oliver J. (skriptkiddy)]

Christoph abc schrieb:
> Nur wieso funktioniert es denn bei dir?
Weiß ich nicht.

Gruß Oliver

[Entwickler (Gast)]

Hallo,

ich habe das Beispiel auf den STM32F207 angepasst. Das Compilieren und 
Linken funktioniert. Jetzt möchte ich mit dem IAR JLink Debugger über 
den GDB Server debuggen und auch flashen können. Welche Einstellungen 
müsste ich in Eclipse sowie im OpenOCD File vornehmen ?

[Andreas R. (rebirama)]

Hi,

Ich versuche gerade dein Beispiel auf einem stm32F103VET6 zum laufen zu 
bringen, bisher ohne Erfolg.

Was es Tut:
Es compiliert,
die *_init() sache werden noch ausgeführt (per LED getestet), aber kommt 
aus dem "xTaskCreate" nicht mehr zurück und führt auch keine Code in den 
Tasks aus.

Was ich bisher gemacht habe:
1)
#define STM32F10X_HD in einkommentiert, da es ja ein HD-Device ist.

2)
den inhalt der startup.s gegen den aus einer startup_stm32f10x_hd.s 
getauscht.
die FeeRTOS-spezifischen Änderungen (Umbenennungen der ISR-Vektoren des 
Systick-Timers etc.) habe ich aus deiner Version mitgenommen.
Die weak aliases waren auch in deiner Version unverändert.

Hab ich irgendwas übersehen?

[Entwickler (Gast)]

Guten Morgen,

bin leider noch nicht weitergekommen. Welche Einstellungen müsste ich 
vornehmen, damit ich mit dem JLink Debugger von IAR auf dem STM32F207 
debuggen kann ?

[Oliver J. (skriptkiddy)]

Andreas R. schrieb:
> Hab ich irgendwas übersehen?

Das verwendete Linkerskript ist für 128kB Flash und 20kB RAM. Eventuell 
muss man da noch was nachjustieren.

Gruß Oliver

[Andreas R. (rebirama)]

@ Oliver, danke für den Tip, aber das habe ich auch schon gemacht, nur 
vergessen zu erwähnen.

3)
Linkerscript wurde angepasst:

MEMORY
{
  RAM      (RWX) : ORIGIN = 0x20000000     , LENGTH = 64K
  FLASH    (RX)  : ORIGIN = 0x08000000     , LENGTH = 512K
  FLASHB1 (rx)  : ORIGIN = 0x00000000, LENGTH = 0
  EXTMEMB0 (rx) : ORIGIN = 0x00000000, LENGTH = 0
  EXTMEMB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0
  EXTMEMB2 (rx) : ORIGIN = 0x00000000, LENGTH = 0
  EXTMEMB3 (rx) : ORIGIN = 0x00000000, LENGTH = 0
}

/* higher address of the user mode stack */
_estack = ORIGIN(RAM)+LENGTH(RAM);

[Oliver J. (skriptkiddy)]

Entwickler schrieb:
> bin leider noch nicht weitergekommen. Welche Einstellungen müsste ich
> vornehmen, damit ich mit dem JLink Debugger von IAR auf dem STM32F207
> debuggen kann ?

Das nutze ich als GDB-Init-Sequence für die JLinkExe von Segger als 
GDB-server:

monitor interface swd
monitor speed 4000
monitor endian little
monitor flash device = STM32F103RB
monitor flash breakpoints = 1
monitor flash download 1
load ./output/main.elf
monitor reset

Gruß Oliver

[Entwickler (Gast)]

Guten Morgen Oliver J.,

vielen Dank. Wie wird der GDB server in Eclipse konfiguriert ?
Wo wird die GDB-Init-Sequence in Eclipse eingefügt ?

Vielen Dank im Voraus!

[Entwickler (Gast)]

Im Dateianhang habe ich mal einen Auszug von der Eclipse Debug 
Konfiguration angehängt. Vielleicht kann mir da jemand genauer sagen was 
ich wo einstellen muss.

[Entwickler (Gast)]

Wenn ich in Eclipse die Debug Konfiguation einstelle und den Button 
Debug drücke erscheint folgende Meldung:

Cannot run program "make" (in directory "C:\STM32\STM32F207_BLINK_LED"): 
CreateProcess error=2, Das System kann die angegebene Datei nicht finden
Error: Program "make" is not found in PATH

[Oliver J. (skriptkiddy)]

Entwickler schrieb:
> Wie wird der GDB server in Eclipse konfiguriert ?
Bei mir gar nicht. Den starte ich immer über die Kommandozeile und 
einstellen braucht man beim Segger JlinkGDBServer (nicht JlinkExe) auch 
nichts. Bei mir wird alles über die Init Commands vom arm-none-linux-gdb 
aus eclipse heraus erledigt. Wie das geht hab ich dir bereits gezeigt.


Entwickler schrieb:
> Cannot run program "make" (in directory "C:\STM32\STM32F207_BLINK_LED"):
> CreateProcess error=2, Das System kann die angegebene Datei nicht finden
> Error: Program "make" is not found in PATH
Steht doch da wo das Problem liegt. Make kann nicht gefunden werden, 
weil der Installationsordner nicht in der PATH-Umgebungsvariable 
eingetragen ist.


Entwickler schrieb:
> Vielleicht kann mir da jemand genauer sagen was
> ich wo einstellen muss.

Im Bild1: dort muss bei application das elf-file eingetragen werden.

Im Bild2: Versuchen auf TCP 2331 einzustellen

Im Bild3: nur einen Haken bei Load Symbols und die Init-Sequenz in das 
obere
          Textfeld.

Dann brauchst du eigentlich nur noch vorm Debuggen den JlinkGDBServer in 
einer Konsole starten und es sollte funktionieren.

Gruß Oliver

[Entwickler (Gast)]

Hallo Oliver J.,

ich habe jetzt versucht deine Angaben umzusetzen. Welche EXE Datei 
müsste ich starten ? Ich habe im IAR Programmverzeichnis folgende EXE 
Dateien die den IAR JLINK Debugger betreffen.

JLinkTCPIPServer.exe
JLinkSTM32.exe
JLinkConfig.exe
jlink.exe

Das mit dem make und der PATH Umgebungsvariable bereitet mir noch 
Probleme.
Wo muss ich dies einstellen ? in Eclipse ?

[Entwickler (Gast)]

Welches make wird da verlangt ? Steht das make für das makefile ?
Das verstehe ich leider nicht.

[Entwickler (Gast)]

In Bild2 unter Debugger GDB Command habe ich nun folgende EXE Datei 
eingetragen arm-none-eabi-gdb.exe

Das mit dem make macht mir noch Probleme.

[Entwickler (Gast)]

Den Segger JlinkGDBServer finde ich auf dem Rechner nicht. Muss diese 
Software noch zusätzlich heruntergeladen werden ?

[Entwickler (Gast)]

Ich habe für das Debuggen kein make erzeugt. Deshalb verstehe ich auch 
nicht, warum ein make verlangt wird.

[Oliver J. (skriptkiddy)]

Entwickler schrieb:
> Ich habe für das Debuggen kein make erzeugt. Deshalb verstehe ich auch
> nicht, warum ein make verlangt wird.
Eclipse führt bei mir standardmäßig ein make all aus vor dem Debug.
Nimm das Make hier:
http://gnuwin32.sourceforge.net/packages/make.htm

Entwickler schrieb:
> Den Segger JlinkGDBServer finde ich auf dem Rechner nicht. Muss diese
> Software noch zusätzlich heruntergeladen werden ?
http://www.segger.com/jlink-gdb-server.html

Entwickler schrieb:
> Das mit dem make und der PATH Umgebungsvariable bereitet mir noch
> Probleme.
> Wo muss ich dies einstellen ? in Eclipse ?

Das stellt man in Windows ein.


Gruß Oliver

[Entwickler (Gast)]

Ich verwende den MinGW GCC.

Wie kann ich dies unterbinden, dass vor dem Debug make all ausgeführt 
wird ? Da ich MinGW GCC einsetze, wie kann ich dies in Eclipse 
einstellen, dass statt make all MinGW GCC gestartet wird ?

[Entwickler (Gast)]

Ich habe den Haken "Disable auto build" bei der Debug-Konfiguration 
aktiviert. Somit kommt die Fehlermeldung nicht mehr. Nun bekomme ich 
eine weiter Fehlermeldung. So wie es aussieht kann ich mit dem JLink 
nicht auf mein Device zugreifen.

[Oliver J. (skriptkiddy)]

Entwickler schrieb:
> Wie kann ich dies unterbinden, dass vor dem Debug make all ausgeführt
> wird ? Da ich MinGW GCC einsetze, wie kann ich dies in Eclipse
> einstellen, dass statt make all MinGW GCC gestartet wird ?
Was willst du denn mit dem MinGW wenn du für ARM kompilierst?
Weißt du auch nur ansatzweise, was du da tust?

Entwickler schrieb:
> So wie es aussieht kann ich mit dem JLink
> nicht auf mein Device zugreifen.
Der JLinkGDBServer scheint nicht zu laufen.


PS. Kauf dir lieber ne Fertiglösung, da braucht man so gut wie kein 
Hintergrundwissen. Installieren und fertig. Rowley Crossworks könnte 
eine Anlaufstelle sein.

Gruß Oliver

[Entwickler (Gast)]

Hallo Oliver J., ich muss mich leider korrigieren.
Ich verwende kein MinGW GCC sondern CoudeSourcery für ARM. Es geht mir 
eigentlich nur um den JLink Debugger. Irgendwo habe ich was falsches 
bzw. vergessen einzustellen. Wo könnte bei mir noch das Problem liegen ?

[Oliver J. (skriptkiddy)]

Entwickler schrieb:
> Irgendwo habe ich was falsches
> bzw. vergessen einzustellen.
Du musst auf jeden Fall die JLinkGDBserver.exe starten, denn diese 
stellt erst den TCP-Socket "localhost:2331" für den arm-gdb bereit.

Gruß Oliver

[Entwickler (Gast)]

Hallo Oliver J.,

ok vielen Dank. Das werde ich am Montag mal testen.

Dies bedeutet, dass zuerst der JLinkGDBServer.exe gestertet werden muss 
und im Anschluss in Eclipse dann die arm-none-eabi-gdb.exe.

Bye

[Entwickler (Gast)]

Guten Morgen,

ich habe von SEGGER das Softwarepaket für den JLink GDB Server 
heruntergeladen und istalliert. Wenn ich die Datei JLinkGDBServer.exe 
ausführe, wird der JLInk Debugger von IAR auch erkannt. Nun starte ich 
in Eclipse im GDB Hardware Debugging die Datei arm-none-eabi-gdb.exe.
In der Konsole von Eclipse erscheint eine Warnung: warning: RMT ERROR : 
failed to get remote thread list. Ich kann den Code nicht starten. Der 
Debugger in Eclipse zeigt mir Thread [1] <main> (Supsend : User Request) 
0x0 an. Ich kann gar nicht debuggen.

C/C++ Application:
C:\STM32\STM32F207_BLINK_LED\output\main.elf

GDB Setup
GDB Command:
C:\CodesourceryARM\arm-2011.09\bin\arm-none-eabi-gdb.exe

Remote Target
JTAG Device: Generic TCP/IP
Hoast name or IP address: localhost
Port number: 2331

Initialization Commands:
monitor interface swd
monitor speed 5000
monitor endian little
monitor flash device = STM32F207IG
monitor flash breakpoints = 1
monitor reset

Load symbols
Use project binary:
STM32\STM32F207_BLINK_LED\output\main.elf

[Entwickler (Gast)]

Ich habe auch mal diese Kommandos benutzt:
monitor interface swd
monitor speed 1000
monitor endian little
monitor flash device = STM32F207IG
monitor flash breakpoints = 1
monitor flash download 1
load ./output/main.elf
monitor reset
monitor reg r13 = (0x00000000)
monitor reg pc = (0x00000004)
#after load:
monitor reset
continue

[Entwickler (Gast)]

Wenn ich folgende Kommandos verwende:

>>set mem inaccessible-by-default off
>>monitor interface swd
>>monitor speed auto
>>monitor endian little
>>monitor flash device = STM32F207IG
>>monitor flash breakpoints = 1
>>monitor flash download 1
>>load ./output/main.elf
>>break main
>>monitor reg r13 = (0x00000000)
>>monitor reg pc = (0x00000004)
>>monitor reset
>>continue

erhalte ich folgende Meldung von Eclipse:

Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:2331

Error message from debugger back end:
localhost:2331: Ein Verbindungsversuch ist fehlgeschlagen, da die 
Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, 
oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host 
nicht reagiert hat.

[Oliver J. (skriptkiddy)]

Entwickler schrieb:
> Warnung: warning: RMT ERROR :
> failed to get remote thread list.
Das kommt bei mir auch und das Debuggen funktioniert trotzdem.

Versuch es doch erst einmal über die Konsole. Wenn das dann 
funktioniert, dann kann man sich daran machen diese Geschichte in 
Eclipse zum Laufen zu bringen.

Den GDB-startest du so:

arm-none-eabi-gdb STM32\STM32F207_BLINK_LED\output\main.elf

Dann führe mal folgende Befehle im GDB-Commandline-Interface Zeile für 
Zeile aus:

target remote :2331
monitor interface swd
monitor speed 1000
monitor endian little
monitor flash device = STM32F207IG
monitor flash breakpoints = 1
monitor flash download 1
load ./output/main.elf
break main
monitor reset
continue

Mit Strg+c kannst du das Programm anhalten. Mit continue gehts weiter.


Entwickler schrieb:
> Error message from debugger back end:
> localhost:2331: Ein Verbindungsversuch ist fehlgeschlagen, da die
> Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat,
> oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host
> nicht reagiert hat.
Manchmal kann es helfen den Jlink auf der USB-Seite neu zu verbinden.

Gruß Oliver

[Entwickler (Gast)]

Hi Oliver J.,

danke. Ich kann nun debuggen. Das ist schonmal super!

Ich meiner Applikation starte ich zunächst einen Task.
Der Task wird allerdings nur einmal angesprungen. Das verstehe ich nicht 
ganz.

/* Include STM32 Firmware Lib Headers */
#include "stm32f2xx.h"
#include "stm32_eval.h"

/* Scheduler include files. */
#include "FreeRTOS.h"
#include "task.h"
#include "croutine.h"

// Function Declarations
int main(void);
void vLeds(void* dummy);

unsigned int retTaskCreate=0;

/* Main function */
int main(void)
{
  STM_EVAL_LEDInit(LED1);
  STM_EVAL_LEDInit(LED2);
  STM_EVAL_LEDInit(LED3);

  STM_EVAL_LEDOn(LED1);
  STM_EVAL_LEDOn(LED2);

  retTaskCreate = xTaskCreate(vLeds,(signed char*)"Led",100,0,10,0);

  vTaskStartScheduler();

  /* Here the devil lives */
  while(1)
  {
    STM_EVAL_LEDOn(LED3);
  }
    return 0;
}

/* Controls 4 LEDs (chaser light) */
void vLeds(void* dummy)
{
  STM_EVAL_LEDOff(LED1);
  STM_EVAL_LEDOff(LED2);
  vTaskDelay(500);
  STM_EVAL_LEDOn(LED1);
  STM_EVAL_LEDOn(LED2);
}

[Oliver J. (skriptkiddy)]

Entwickler schrieb:
> void vLeds(void* dummy)
> {
>   STM_EVAL_LEDOff(LED1);
>   STM_EVAL_LEDOff(LED2);
>   vTaskDelay(500);
>   STM_EVAL_LEDOn(LED1);
>   STM_EVAL_LEDOn(LED2);
> }

Da fehlt die Endlosschleife.

void vLeds(void* dummy)
{
   while(42) {
     STM_EVAL_LEDOff(LED1);
     STM_EVAL_LEDOff(LED2);
     vTaskDelay(500);
     STM_EVAL_LEDOn(LED1);
     STM_EVAL_LEDOn(LED2);
   }
}

Gruß Oliver

[Entwickler (Gast)]

Hmmm, ok stimmt. Danke!

[Andreas R. (rebirama)]

Hi,

hab inzwischen zum laufen bekommen.

Es lag nich an deinem Paket Oliver, sonder vermutlich an meiner 
toolchain.

Ich verwende die summon-arm-toolchain, mit der ich bisher gute 
Erfahrungen gemacht habe (bisher = ohne FreeRTOS).

Ich hab den Fehler soweit zurückverfolgen können: Er springt beim 
Starten der Tasks in den HardFault_Handler.
Beheben konnte ich das Verhalten, in dem ich den Aufruf der strncpy 
funktion aus der <string.h> durch das RTOS durch eine einfache selbst 
implementierte Version von strncpy ersetzt habe. (strncpy wird verwendet 
um den Task-Name zu kopieren).

Warum die Nutzung einer Funktion aus <string.h> einen Hard-Fault 
auslößt: keine Ahnung. Vielleicht kann das jemand anders beantworten.

Danke Oliver für das onlinstellen deines Minimaldemos!

[Oliver J. (skriptkiddy)]

Andreas R. schrieb:
> Warum die Nutzung einer Funktion aus <string.h> einen Hard-Fault
> auslößt: keine Ahnung. Vielleicht kann das jemand anders beantworten.

Ein ähnliches Problem hatte ich Anfangs auch. Und zwar blieb bei mir 
auch jedes mal das System im Hardfault-Handler hängen. Der Grund war, 
dass der Linker die 32-Bit arm-Code-Variante von strcpy gelinkt hatte. 
Der Fehler lag natürlich bei mir. Ein Cortex-M kann ja bekanntlich nur 
Thumb(2)-Code ausführen, sodass er sich an 32-Bit-Code die Zähne 
ausbeißt.

Einen solchen Fehler kann man leicht finden, indem man sich mal das 
Assembler-Listing ansieht: Wenn in der Spalte mit den hex-kodierten 
Befehlen bei strcpy etwas auftritt, was 32 Bit breit ist, dann wurde 
wahrscheinlich nicht die Thumb-Version gelinkt.

Gruß Oliver

[Entwickler (Gast)]

Hi, letzte Woche hatte ich den Debugger zum Laufen gebracht. Nun ist es 
allerdings so, dass es Probleme mit dem GDB Debugger gibt.

Disassembly in Eclipse:

00000000:   Failed to execute MI command:
          -data-disassemble -s 0 -e 76 -- 1
          Error message from debugger back end:
          Cannot access memory at address 0x0

Was könnte da die Ursache für dieses Fehlverhalten sein ?

[Entwickler (Gast)]

Ich verstehe das einfach nicht. Warum funktioniert plötzlich der GDB 
Debugger nicht mehr. Vor jedem debuggen starte ich manuell die Software 
"JLinkGDBServer.exe".

Wenn sich jemand mit dieser Fehlermeldung auskennt, wäre ich sehr 
dankbar für die Unterstützung.

[Oliver J. (skriptkiddy)]

Mach bitte einen eigenen Thread dafür im Bereich µC-Elektronik auf.

[Leonhardt (Gast)]

Hallo Oliver J.,

ich habe ein Evaluationboard von STMicroelectronics "STM32VLDISCOVERY" 
mit dem STM32F100 Mikrocontroller.
Link: http://www.st.com/internet/evalboard/product/250863.jsp

Eclipse sowie Codesourcery habe ich laut dieser Anleitung installiert.
Link: 
http://www.chibios.org/dokuwiki/doku.php?id=chibios:guides:eclipse1

Ich habe nun das FreeRtos Projekt heruntergeladen und mit Eclipse habe 
ich das Projekt geöffnet. Den Link habe ich bei CROSS_COMPILE auch 
angepasst.
Wie kann ich nun in Eclipse das Projekt kompilieren ? Ich finde kein 
MakeTarget.

[Oliver J. (skriptkiddy)]

Leonhardt schrieb:
> Wie kann ich nun in Eclipse das Projekt kompilieren ? Ich finde kein
> MakeTarget.

Unter Project properties -> C/C++ Build -> Use default Build Command
den Haken entfernen.

Gruß Oliver