Skip to main content

FreeRTOS + newlib (gcc toolchain) on the STM32F103 (Cortex-M3)

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 */
#define vPortSVCHandler SVC_Handler
#define xPortPendSVHandler PendSV_Handler
#define xPortSysTickHandler SysTick_Handler
Neglecting to perform this mapping was causing me to see odd exceptions such as the usb lp handler being called:


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

Popular posts from this blog

Debugging an imprecise bus access fault on a Cortex-M3

This information may apply to other cortex series processors but is written from practical experience with the Cortex-M3. Imprecise bus access faults are ambiguous, as noted by the term "imprecise". Compared to precise bus errors, imprecise errors are much trickier to debug and especially so without a deep understanding of arm processors and assembly language. Imprecise and precise flags are found in the BusFault status register, a byte in the CFSR (Configurable Fault Status Register). BusFault status register bits The definition for imprecise and precise bits is: [2] IMPRECISERR Imprecise data bus error: 0 = no imprecise data bus error 1 = a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. This is an asynchronous fault. Therefore, if it is detected when the priority of the current pr...

Travelling on Spirit airlines out of Boston Logan airport? Here are some tips.

I attended CES 2017 in Las Vegas. Booking the trip late I ended up on Spirit airlines. It was both non-stop, making it six hours to Las Vegas from Boston, and affordable, less than $300 for a one way trip compared to around $700 with JetBlue. Here are some tips that might help you when travelling on Spirit from Boston Logan airport. Eat Spirit is located in the B-terminal, gates B-37 and 38, with its own TSA security checkpoint. While it does have restrooms and places to sit the food selection is limited to a single food stand. I'd recommend eating at the Legal C Bar (number 77 in the image below) prior to going through the terminal security checkpoint. The food and service there were great. Drink The water and other drinks are cheaper if you buy them at the food cart rather than on the flight. Seats The seats on Spirit don't recline. They do this to reduce weight, seat cost, seat maintenance costs, and so seats don't impact the free space of other passengers,...

Yocto recipe SRC_URI for a BitBucket / GitHub ssh git repository

This is a particularly geeky post but because Google searches didn't turn up any information I thought it would be helpful to document the issue and solution for others. I was writing  Yocto recipes that pulled from BitBucket git repositories in ssh form and ran into several issues getting a SRC_URI that worked. GitHub uses the same syntax for their ssh repositories. A BitBucket / GitHub git url, in ssh form, looks like: < username >@bitbucket.org:< account name >/< repository name >.git a more concrete example for a git repository in one of my BitBucket accounts looks like: git@bitbucket.org:cmorgan/somerepository.git Yocto recipes can pull from git repositories by setting the SRC_URI variable appropriately. Unfortunately you can't just do: SRC_URI = "git@bitbucket.org:cmorgan/somerepository.git You'll get errors because the Yocto won't know what kind of url this is. You need to specify the protocol for Yocto to k...