Here are some of the steps to get FreeRTOS and newlib (gcc) to work correctly on the STM32F10x, a Cortex-M3 ARM processor.
Configure the priority bits
Per the FreeRTOS page about the Cortex M3 and M4, the priority bits should be assigned to be preempt priority by calling NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 ); If you or any start up related code you are using isn't doing this you may end up with odd behavior or bus faults.
Map FreeRTOS tasking functions to CMSIS vector handlers
Per this post you'll want to map the FreeRTOS handlers for vPortSVCHandler, xPortPendSVHandler and xPortSysTickHandler to the CMSIS handlers. A readelf of the elf file of my example application was showing the default interrupt handler was being used for those interrupts, which meant FreeRTOS wasn't handling the interrupts it needed to function correctly. The CMSIS default handlers are weakly bound so having other definitions with the same names will override these, causing the FreeRTOS handlers to be called instead of the default vector handler.
You can do this by adding these lines to your FreeRTOSConfig.h file:
/** Defines to map FreeRTOS tasking functions to CMSIS standard vector table entries */Neglecting to perform this mapping was causing me to see odd exceptions such as the usb lp handler being called:
#define vPortSVCHandler SVC_Handler
#define xPortPendSVHandler PendSV_Handler
#define xPortSysTickHandler SysTick_Handler
Newlib reentrancy handling
If you are building newlib with reentrancy support, support for calling library functions at the same time from multiple threads, then you'll have to take some care to configure newlib properly at run-time. There isn't much information about this topic, it may be that newlib isn't often used with FreeRTOS on smaller embedded systems.
During a bringup of FreeRTOS and newlib I kept seeing imprecise bus faults at start up. Debugging narrowed the fault down to a call to malloc() which was calling _malloc_r(). A few hours of stepping through the source code revealed that _REENT (also defined as impure_ptr), a struct _reent*, appeared to be invalid. Some searching brought up this thread. There also appears to be a global reent structure called _impure_data that is assigned to _global_impure_ptr. Nothing appears to be using this pointer or assigning it to _REENT though, which is why the imprecise bus fault happened. The above thread shows how to integrate the configuration of impure_ptr with thread switching. This ensures that there is a struct _reent for each thread and that impure_ptr is set as the thread is activated to run.
As a temporary work around I added this call at the start of main():
_REENT_INIT_PTR(_REENT);
I've posted on the FreeRTOS support forums and upon Richard's request posted a feature request for the changes to be made to the FreeRTOS code to support newlib natively. If FreeRTOS gets newlib support it should be a matter of setting the appropriate config flag in FreeRTOSConfig.h and you'll be able to avoid dozens of hours tracking down this issue and patching FreeRTOS to fix it.
Comments
Post a Comment