Chris M.

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 th...

A test application using FreeRTOS and an arm cross compiler was landing in the default exception handler during the start up code in main(). Because several of the exception handlers are still using the default exception handler the debugger indicates WWDG_IRQHandler. Some googling turned up this post  but while mapping the FreeRTOS handlers with #defines did correct something I had missed it wasn't the cause of the exceptions. Single stepping through the code narrowed the issue down to a call to malloc(), in at a label called _malloc_from_thumb(). The particular instruction was "bx pc". When the 'bx pc' was executed the processor jumped directly to the watchdog isr handler. Next I ran 'objdump -d -S -l' on the elf file and started looking at the code and assembly. main() looks like: _malloc_from_thumb(): looks like: You can see that this function has a couple of 16 bit thumb instructions and then a 32 bit arm instruction. Its purpose, a...

This site was quite useful in setting up Eclipse with the cross tool chain. The one thing I missed the first time was that the compiler prefix should end in a hyphen. Since I left that off I had to manually correct some of the paths in the project configuration.

After getting a gcc toolchain for ARM built the next step was to build a simple "Hello world" application. I put together something simple to set an output and toggle it: #include "stm32f10x.h" #include "stm32f10x_rcc.h" #include "stm32f10x_gpio.h" const static int DelayCount = 2500000; void Delay() { volatile int delayValue; delayValue = DelayCount; while(delayValue) { delayValue--; } } int main() { // enable gpio c clock, IOPCEN bit RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE); // configure PC12 as output, open drain GPIO_TypeDef* gpio = GPIOC; GPIO_InitTypeDef gpioInit; GPIO_StructInit(&gpioInit); gpioInit.GPIO_Mode = GPIO_Mode_Out_OD; gpioInit.GPIO_Pin = GPIO_Pin_12; GPIO_Init(gpio, &gpioInit); // loop forever while(1) { // output 1 on PC12 GPIO_SetBits(gpio, GPIO_Pin_12); Delay(); // output 0 on PC12 GPIO_ResetBits(gpio, GPIO_Pin_12); Delay(); } ...

I've been a big fan of crosstool-ng ever since I found out that Dan Kegal's crosstool scripts  idea was being continued. I picked up one of these boards, an Olimex STM32-H103 , because I'm putting together a custom PCB with an STM32F103 on it and didn't want to be bringing up the toolchain at the same time as debugging the hardware. Starting with this board means starting with a known working STM32F103 board. Steps - Install 'gcc-multilib' package. If you don't have this you'll get some odd errors when building the toolchain such as: [INFO ] ================================================================= [INFO ] Installing binutils for host [INFO ] Installing binutils for host: done in 142.17s (at 11:46) [INFO ] ================================================================= [INFO ] Installing pass-1 core C compiler [ERROR] checking dynamic linker characteristics... checking whether getchar_unlocked is declared... configure: er...