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.

Labels:

Comments

Post a Comment

Popular posts from this blog

UTM (qemu on OSX) only boots into uefi shell after installing Ubuntu 22.10 (solved!)

I've been meaning to try out running Linux and Windows virtual machines on my x86 MacBook Pro using qemu . I've been using Parallels for several years. Parallels is a nice application and works well but I'm always getting bugged to purchase upgrades. Parallels provides free updates on minor version upgrades only, say 13.0 to 13.1. With so many prompts to purchase upgrades it feels like Parallels could release a bit more minor versions and a bit fewer major versions. Rather than just purchase an upgrade to Parallels I figured I'd try out qemu via the UTM application . UTM wraps qemu with a helpful gui and comes as a packages Mac application. And UTM supports both x86 and M1 systems (as qemu also supports these systems). Creating an Ubuntu VM with UTM didn't go as smoothly as with VirtualBox or Parallels but it was the settings I chose that messed me up. Here are two things I ran into when installing Ubuntu on UTM. #1. Configure the qemu instance to use a 'Display...
Post a Comment
Read more

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...
5 comments
Read more

Graco Swing By Me - Battery to AC wall adapter modification

If you have one of these Graco battery powered swings you are probably familiar with the cost of C batteries! The swing takes four of them and they only last a handful of days. I'm not sure if the newer models support being plugged into the wall but ours didn't. If you are a little familiar with electronics and soldering, here is a rough guide on how you can modify yours to plug in! I wasn't sure how exactly to disassemble the swing side where the batteries were. I was able to open up the clamshell a bit but throughout this mod I was unable to determine how to fully separate the pieces. I suspect that there is some kind of a slip plate on the moving arm portion. The two parts of the plastic are assembled and the moving arm portion with the slip plate is slid onto the shaft. Because of the tension in that slip plate it doesn't want to back away, and because of the mechanicals that portion of the assembly doesn't appear accessible in order to free it. I was...
Post a Comment
Read more