Chris M.

The version control system your project uses can have a big impact on how easy it is for outside contributors to help out. Svn (and cvs) make it difficult to contribute Most projects restrict new or minor contributors to read only permission on their code repositories. This is common both for security and for organizational purposes, project maintainers often like to review changes before they go into mainline code. Read only access has its downside for contributors. If someone like myself wanted to contribute to a project that used svn the flow wold look something like: - svn checkout - Edit files in my editor - Test - svn diff > changes.patch - Email/post changes to maintainer - Wait until the changes are approved or rejected and checked in to svn - Repeat starting at 'Edit files in my editor' The bottleneck here is waiting for changes to be checked into svn. What if there were several changes in series? How would I be able to continue working on the next chang

CMSIS-SVD is "Cortex Microcontroller Software Interface Standard" "System View Description". This is an ARM standard format for describing the registers and their bitfields for the Cortex-M series of ARM processors. If you have an account on the Arm website you can visit the STMicro cmsis page  where you can download the svd files for various STMicro processors. The STM32F10x svd files however appear to be missing important things like the system control block . This is an issue because I've been using the Eclipse plugin EmbSysRegView  to browse cpu registers during debug. The system control block is important because it contains various status registers that report fault status. These registers can help to locate issues in code or configuration. I posted a support question with ST and on their forums to see why their CMSIS-SVD doesn't appear to include all of the processors registers but I'll probably end up modifying the other EmbSysRegView proc

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

Embedded processors tend to require a registers configuration beyond the traditional CPU registers found in the x86 architecture. Power, interrupts, clocks, I/O hardware modules can have from several to dozens of different registers that contain configuration settings. Having to find the address for each register is relatively painful. Some processors make it even more difficult with a configurable base address. Once you've found the address you want you still have to figure out what the bits in the register mean and which configurations are valid. Embedded development Integrated Development Environments (IDEs) like IAR's Embedded Workbench provide helpful address to value mappings for internal registers. EmbSys RegView is a plugin for Eclipse that breaks out the processors registers and fields (although it appears to lack a mapping for the meaning of the individual fields and the valid values). Eclipse EmbSys Registers pane

Why? I've been bringing up a gcc toolchain for ARM, specifically the STM32. So far the toolchain looks good. I'm able to build binaries with it and downloading and debuging via OpenOCD, a STLINK/V2 low cost debugger and gdb works as expected. Gdb as an interface is fine but I find it helps to take advantage of a modern gui while debugging. Eclipse made it easy to configure the build with the cross compiler toolchain and it has a pretty good debugging interface. Some of the benefits of using an IDE are having multiple windows open to view registers and view several source files at once, searching and easily traversing the call stack. I'm not normally a fan of gui apps but sometimes it does help to have several sets of information visible at once during debugging. Get the right version of Eclipse I spent several hours trying to get openocd gdb to work with Eclipse Indigo(?) v3.8.1, the version in Ubuntu/Kubuntu 13.04. I even tried with the Zylin plugin. Nothing seeme

ST has newer versions of the STM32 standard peripheral library that aren't being released. If you search on the website you'll find v3.5.0, dated as released 11-March-2011. But, if you download the STM32 USB-FS_Device driver package you can see that this includes a much newer STM32 standard peripheral library, v3.6.1 dated 05-March-2012. There are some quite important fixes between v3.5.0 and v3.6.1: V3.6.1 / 05-March-2012 Main Changes All source files: license disclaimer text update and add link to the License file on ST Internet. V3.6.0 / 27-January-2012 Main Changes All source files: update disclaimer to add reference to the new license agreement stm32f10x_sdio.c SDIO_SetPowerState() function: fix POWER register configuration, only one access (for read or write) is allowed stm32f10x_usart.h/.c Update procedure to check on overrun error interrupt pending bit, defines for the following flag are added: USART_IT_ORE_RX: this flag is set if overrun err

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