Hallo, I’m trying to use FreeRTOS(8.0.1) + newlib nano shipped with ARM GCC (https://launchpad.net/gcc-arm-embedded)
I did everything according to article: http://michaldemin.wordpress.com/2010/03/09/freertos-newlib-on-cortex-m3/
so my malloc and free functions looks like these: https://github.com/robots/STM32/blob/master/lib/FreeRTOS/portable/MemMang/alloc.c
I have also added configUSE_NEWLIB_REENTRANT 1 to FreeRTOSConfig.h
Every things looks to work ok. I have got 3 tasks running on the same priority and they are printing float values using semihosting.
Things get changed when I delete one of task using vTaskDelete()… scheduler is still running but there is no output data. And when I change the printf to sprint I got occasionally hardfault.
Do I missing something in newLib port? Or FreeRTO is messing something with the _reent struct while deleting task?
Best Regards, Krzysztof
you will see that _reclaim_reent is called when a Task’s TCB is deleted. This was only put in very recently. Do you still get the problem if you take it out? Note it can’t be left out as it may result in a memory leak, so this suggestion is just an experiment.
The caveat with this newlib stuff is always that we don’t use it ourselves, as we generally try and avoid newlib, so we are reliant on its users keeping us informed of its behaviour.
Yes, after comment out line 3097("_reclaim_reent( &( pxTCB->xNewLib_reent ) );") in the tasks.c everything works ok. But how prevent memory leakage and delete the _reent structure correlated with the task which is being deleted.
You said that You are not using newlib, am I right? What are You using instead? NewLib have a lots of useful function and not all of them are costly …. How to determine which I can use safely within FreeRTOS and which I can’t?
I would have to investigate how the deleting of the reent structure works in the nano version, but also note from your first post you are using third party code and adding in your own interface functions - so we can’t support those parts.
As mentioned, I have never written a system that made use of the reent features. Many professional tools I have used that ship with GCC (Red Suite/LPXpresso, Rowley, etc.) ship with their own library implementation. Even when Newlib is used I just have never had a requirement to use the reent struct so my experience in that area is negligible. Also I would normally replace the functions that required the reent structs with my own versions (there is a super skinny version of scanf/printf used in many demos) to allow me to keep the stack usage under control. Generally memory allocation/de-allocation is kept to the minimum possible, with nothing more required than the schemes provided within FreeRTOS itself (one of which is the standard library malloc and provide what you need?).
It seems that, when calling _reclaim_reent(arg) with arg different from _impure_ptr, Newlib is closing stdin/stdout/stderr handles (although it shouldn’t).
A possible solution is to set the pointers to the file handles to NULL so that they don’t get closed, e.g.,
FILE * fp = &(arg->__sf[0]);
int i;
for (i = 0; i < 3; ++i, ++fp) {
fp->_close = NULL;
}
_reclaim_reent(arg);
An alternative could be to set _impure_ptr = arg, call _reclaim_reent, then restore _impure_ptr.