STM32 FreeRTOS Projekt (Makefile - GCC)

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 schrieb:
> mit welchen Freewaretool tust du dann debuggen ?

openocd + gdb + eclipse

Gruß Oliver

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:

1

#daemon configuration

2

telnet_port 4444

3

gdb_port 4242

4

5

#interface

6

interface jlink

7

8

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

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

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

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

Versuch mal folgende LD_FLAGS:

1

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

Gruß Oliver

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).

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

Huch falscher Account.

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

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

Wie versprochen hier die überarbeitete Variante.

Gruß Oliver

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

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

Gruß Oliver

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?

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

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

3)
Linkerscript wurde angepasst:

1

MEMORY

2

{

3

  RAM      (RWX) : ORIGIN = 0x20000000     , LENGTH = 64K

4

  FLASH    (RX)  : ORIGIN = 0x08000000     , LENGTH = 512K

5

  FLASHB1 (rx)  : ORIGIN = 0x00000000, LENGTH = 0

6

  EXTMEMB0 (rx) : ORIGIN = 0x00000000, LENGTH = 0

7

  EXTMEMB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0

8

  EXTMEMB2 (rx) : ORIGIN = 0x00000000, LENGTH = 0

9

  EXTMEMB3 (rx) : ORIGIN = 0x00000000, LENGTH = 0

10

}

11

12

/* higher address of the user mode stack */

13

_estack = ORIGIN(RAM)+LENGTH(RAM);

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:

1

monitor interface swd

2

monitor speed 4000

3

monitor endian little

4

monitor flash device = STM32F103RB

5

monitor flash breakpoints = 1

6

monitor flash download 1

7

load ./output/main.elf

8

monitor reset

Gruß Oliver

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 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 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 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 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:

1

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:

1

target remote :2331

2

monitor interface swd

3

monitor speed 1000

4

monitor endian little

5

monitor flash device = STM32F207IG

6

monitor flash breakpoints = 1

7

monitor flash download 1

8

load ./output/main.elf

9

break main

10

monitor reset

11

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 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.

1

void vLeds(void* dummy)

2

{

3

   while(42) {

4

     STM_EVAL_LEDOff(LED1);

5

     STM_EVAL_LEDOff(LED2);

6

     vTaskDelay(500);

7

     STM_EVAL_LEDOn(LED1);

8

     STM_EVAL_LEDOn(LED2);

9

   }

10

}

Gruß Oliver

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!

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

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

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