gcc-none-eabi-arm on Cortex-M0 woes

Need help with C, C++, perl, python, etc?

gcc-none-eabi-arm on Cortex-M0 woes

Postby jrandomdud » 2016-08-06 00:10

Hi Guys,

Figured this was probably the best place to post this as it relates to the packaged toolchain from the Debian repository.

I'm in the process of developing some firmware for a device based on an ARM Cortex-M0 processor (specifically the STM32F051), to do this I'm using the gcc-arm-none-eabi toolchain from the Debian Jessie repo. My toolchain/build environment is up and working a this stage but I've run into some snags.

The Cortex-M0 only supports thumb instructions, however it appears that the linker is pulling in the ARM version of (presumably) newlib.

Any usercode I write is fine until the point that it calls out, at which point my processor HardFaults. Backtracing I always find that the cause of the HardFault is due to a call to an __aeabi_<somefunc>_from_thumb api, looking at the disassembly around the area of the code in question, it appears to be a stub to switch instruction mode to ARM and call an ARM function, which of course doesn't work on a thumb-only processor.

Example disassembly;
Code: Select all
08001798 <____aeabi_uidiv_from_thumb>:
 8001798:       4778            bx      pc
 800179a:       46c0            nop                     ; (mov r8, r8)
 800179c:       eafffa48        b       80000c4 <__aeabi_uidiv>


It seems that rather than pulling in the thumb versions of newlib it's pulling in ARM code instead.

My CFLAGS are;
-mlittle-endian -mcpu=cortex-m0 -march=armv6-m -mthumb -Wall -g -O0 -mfloat-abi=soft -ffunction-sections -fdata-sections -ffreestanding -nostdlib --specs=nano.specs

My LDFLAGS are;
-Wl,--gc-sections,-Map=$@.map,-cref $(INCLUDE_DIRS) $(LIBRARY_DIRS) -T stm32.ld

INCLUDE_DIRS is;
-I . -I $(PERIPH_LIB_PATH)$(PERIPH_DRIVER_PATH)inc -I $(PERIPH_LIB_PATH)CMSIS/Include

LIBRARY_DIRS is;
-L . -L $(PERIPH_LIB_PATH)$(PERIPH_DRIVER_PATH)src -L linker

PERIPH_LIB_PATH just points to the ST Micro provided Peripherals Library.

Initially I wondered if it was because there were no architecture specific libs under /usr/lib/arm-none-eabi/newlib i.e. no armv6-m directory there, so I pulled in Jessie Backports because the 4.9.4 package there did have an armv6-m directory in the lib tree, this doesn't appear to have made any difference, I also tried explicitly adding the armv6-m directory to my LIBRARY_DIRS, again no change.

I'm very new to this whole cross-compiling malarkey so it's entirely possible I'm just doing something stupid.

Any assistance would be greatly appreciated.

Thanks

-J
jrandomdud
 
Posts: 3
Joined: 2016-08-05 23:34

Re: gcc-none-eabi-arm on Cortex-M0 woes

Postby jrandomdud » 2016-08-07 10:32

Looks like I may have finally stumbled on the answer.

It appears that the problem was that I wasn't passing -mcpu=cortex-m0 to the linker in LDFLAGS, looks like all of the "from_thumb" API calls are gone now.
jrandomdud
 
Posts: 3
Joined: 2016-08-05 23:34

Re: gcc-none-eabi-arm on Cortex-M0 woes

Postby tomazzi » 2016-08-08 21:36

jrandomdud wrote:Looks like I may have finally stumbled on the answer.

It appears that the problem was that I wasn't passing -mcpu=cortex-m0 to the linker in LDFLAGS, looks like all of the "from_thumb" API calls are gone now.


Hi.

Ok, but You have used the -mthumb, so it looks like a gcc bug...

The only explanation which comes to my mind is that by using the -ffreestanding option, the gcc is still linking against libgcc, which is apparently compiled in the ARM mode...

Regards.
Odi profanum vulgus
tomazzi
 
Posts: 730
Joined: 2013-08-02 21:33

Re: gcc-none-eabi-arm on Cortex-M0 woes

Postby jrandomdud » 2016-08-08 22:28

Yeah, that was my thinking too, I'd have thought passing -mthumb to the linker would've been enough, but evidently it wasn't.

The only way that just adding the -mcpu flag should've changed things was if it was for instance using some Cortex-M3 instruction which isn't supported on the M0, I'm not ARM expert but it certainly looks like the stub code was switching from Thumb to ARM.

I was seeing the same issue without -ffreestanding so I don't know that it's related to that, but then I went through an awful lot of iterations trying to get it to work, I should probably spend some time pulling flags out until it breaks ;)
jrandomdud
 
Posts: 3
Joined: 2016-08-05 23:34


Return to Programming

Who is online

Users browsing this forum: No registered users and 3 guests

fashionable