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, at least it appears relatively clear from the code and the function name, is to go from thumb to arm mode so malloc() (a function with arm instructions) can be called.
The STM32 is a Cortex-M3 processor. It lacks a floating point unit and only supports thumb mode so trying to run arm instructions isn't going to work at all. To ensure that the proper type of code is generated when compiling both software emulation of floating point operations and thumb mode must be enabled. The gcc options are:
Why would malloc, implemented in newlib on this toolchain, be in arm mode when all of the other code was built in thumb mode per the gcc flags? Maybe the toolchain was selecting the arm version of newlib instead of the thumb version?
A search in the cross compiler directory turned this up:
Due to the multi-lib toolchain build there are a few different versions of the standard c library. We probably want to use the thumb/libc.a for the Cortex-M3, given its lack of arm support. I'm using Eclipse here. It has saved me a bunch of time that I would have spent manually adding or excluding files from a makefile or a CMake file, those are easy steps in Eclipse. Eclipse uses gcc for all steps of the build. Apparently this is recommended behavior, I've read on a few sites that one should use gcc both to build objects and to perform the final link, maybe to simplify the process as it pre-selects the correct paths and libraries? If you look in the Eclipse project build settings under Cross G++ Linker->Miscellaneous you'll see that the linker has a "Linker flags" field.
Adding the above gcc flags, including -mthumb, to the Linker flags field solved the problem. Apparently gcc was defaulting to a libc.a that had arm code in it. After rebuilding, the dissassembly of malloc() looks like thumb code, 2 bytes per instruction:
In addition there is no malloc_from_thumb() in the output binary as there isn't a transition between thumb and arm mode anymore.
The system still goes into the default exception during start up but it isn't due to trying to run arm code on a cortex-m3 anymore.
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, at least it appears relatively clear from the code and the function name, is to go from thumb to arm mode so malloc() (a function with arm instructions) can be called.
The STM32 is a Cortex-M3 processor. It lacks a floating point unit and only supports thumb mode so trying to run arm instructions isn't going to work at all. To ensure that the proper type of code is generated when compiling both software emulation of floating point operations and thumb mode must be enabled. The gcc options are:
-mcpu=cortex-m3 -mthumb -mno-thumb-interwork -mfpu=vfp -msoft-float
Why would malloc, implemented in newlib on this toolchain, be in arm mode when all of the other code was built in thumb mode per the gcc flags? Maybe the toolchain was selecting the arm version of newlib instead of the thumb version?
A search in the cross compiler directory turned this up:
$ find -name libc.* ./arm-unknown-eabi/arm-unknown-eabi/sysroot/lib/libc.a ./arm-unknown-eabi/arm-unknown-eabi/sysroot/lib/thumb/libc.a ./arm-unknown-eabi/arm-unknown-eabi/sysroot/lib/fpu/libc.a
Due to the multi-lib toolchain build there are a few different versions of the standard c library. We probably want to use the thumb/libc.a for the Cortex-M3, given its lack of arm support. I'm using Eclipse here. It has saved me a bunch of time that I would have spent manually adding or excluding files from a makefile or a CMake file, those are easy steps in Eclipse. Eclipse uses gcc for all steps of the build. Apparently this is recommended behavior, I've read on a few sites that one should use gcc both to build objects and to perform the final link, maybe to simplify the process as it pre-selects the correct paths and libraries? If you look in the Eclipse project build settings under Cross G++ Linker->Miscellaneous you'll see that the linker has a "Linker flags" field.
Adding the above gcc flags, including -mthumb, to the Linker flags field solved the problem. Apparently gcc was defaulting to a libc.a that had arm code in it. After rebuilding, the dissassembly of malloc() looks like thumb code, 2 bytes per instruction:
In addition there is no malloc_from_thumb() in the output binary as there isn't a transition between thumb and arm mode anymore.
The system still goes into the default exception during start up but it isn't due to trying to run arm code on a cortex-m3 anymore.
Comments
Post a Comment