FreeRTOS - Heap nach Reset

[FreebeerRTOS (Gast)]

Hallo zusammen,

ich habe in meinem STM32F107 FreeRTOS implementiert (Das war ein Kampf 
o.O).
Nun läuft ein Task endlich, jedoch nur zuverlässig nach dem Flashen!
Wenn ich dann den Reset-Taster drücke, lasse ich mir bei Programmstart 
den verfügbaren Heap zurrückgeben. Und nach jedem Reset reduziert sich 
der freie Heap bis keiner mehr verfügbar ist und der Task nicht starten 
kann.

Ich kann mir das gerade nicht erklären. Habt ihr Ideen woran es liegen 
könnte?

[Einer K. (Gast)]

Ich kann nur raten!
Der Statup Code, bzw. Init Code, ist kaputt.

[Mike R. (thesealion)]

Ganz klar, an deinem Programm.

[M.K. B. (mkbit)]

Ich würde tippen, dass die Variablen, die deinen Heap verwalten nach dem 
Reset nicht initialisiert werden. Das würde erklären, warum es nach dem 
Reset nicht klappt, wenn das Teil länger aus ist aber doch.

Möglichkeit 1: In deinem Heapcode fehlt die Initialisierung der 
Variablen oder der Aufruf einer Funktion die das für dich tut.

Möglichkeit 2: Dein Startupcode ruft die Initialisierungroutine des 
Compilers nicht auf in der die Variablen mit ihren Startwerten gefüllt 
werden.

Möglichkeit 3: Der Heapcode verlässt sich auf darauf, dass static 
Variablen mit 0 initialisiert sind (was in C auch richtig ist), aber der 
Startupcode setzt den Datenbereich dafür nicht auf 0.

[Johnny B. (johnnyb)]

FreebeerRTOS schrieb:
> ich habe in meinem STM32F107 FreeRTOS implementiert (Das war ein Kampf
> o.O).

Generiere doch mal den Code samt FreeRTOS mit CubeMX und vergleiche mit 
Deinem Code.
Bei mir funktioniert der generierte Code mit CubeMX einwandfrei.

[FreebeerRTOS (Gast)]

Danke für die Tipps.
CubeMX probier ich gerade aus. Ich wusste gar nicht dass es das auch für 
Linux gibt ;-) .

[FreebeerRTOS (Gast)]

Jetzt habe ich das Startup-File und das Linkerskript von CubeMX genommen 
aber das Problem bleibt (Dateien angehängt).

Ich benutze heap_1.c . Oder empfiehlt sich ein anderes Heap-Management?

[FreebeerRTOS (Gast)]

Hier das Startup-File.

[312313132131 (Gast)]

hi

ich nutze gerne heap_4

heap 1 gibt den speicher nie wieder frei. damit funktioniert quasi 
vPortFree() nicht



was sagt dein .map file wo  "ucHeap" liegt ?

das ist das array mit dem heap - memory mit der größe 
"configTOTAL_HEAP_SIZE "

static uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];

[312313132131 (Gast)]

was hast du mit den ISR :

SVC_Handler
PendSV_Handler

gemacht?

schau mal bitte nach

ggf poste ein archiv mit deinem code

[312313132131 (Gast)]

ich habe in der

FreeRTOSConfig.h dazu 2 defines:

#define vPortSVCHandler        SVC_Handler
#define xPortPendSVHandler     PendSV_Handler

[temp (Gast)]

Es kann doch nicht so schwer sein ein Breakpoint auf den Resethandler zu 
setzen und nach zu sehen was passiert. Es gibt in heap_1.c doch sowieso 
nur die eine Variable (xNextFreeByte) die für den Heap verantwortlich 
ist. Das sollte wesentlich schneller gehen als uns, ohne deine Code zu 
kennen, raten zu lassen.

[A.. P. (arnonym)]

FreebeerRTOS schrieb:
> Ich benutze heap_1.c . Oder empfiehlt sich ein anderes Heap-Management?

Solange du in deinem Code keine Betriebssystemobjekte (also Tasks, 
Queues, Semaphoren etc.) dynamisch erzeugst und wieder freigibst, ist 
das kein Problem.

Die anderen Heap-Varianten sind mehr für den eben genannten Fall und die 
damit einhergehende Fragmentierung des Heaps gedacht.

[Til S. (Firma: SEGGER) (til_s)]

FreebeerRTOS schrieb:
> ich habe in meinem STM32F107 FreeRTOS implementiert (Das war ein Kampf
> o.O).

Gibt es in dem FreeRTOS Paket kein fertiges Projekt, was out of the box 
auf dem STTM32F107 läuft? Alternativ könntest du die Free Variante vom 
embOS benutzen, quasi das FreeEmbOS ;-).
https://www.segger.com/downloads/embos/embOS_CortexM_EmbeddedStudio_Trial
https://www.segger.com/downloads/embedded-studio