Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

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

Programming languages, Coding, Executables, Package Creation, and Scripting.
Post Reply
Message
Author
jrandomdud
Posts: 3
Joined: 2016-08-05 23:34

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

#1 Post by jrandomdud »

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

#2 Post by jrandomdud »

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.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

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

#3 Post by tomazzi »

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

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

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

#4 Post by jrandomdud »

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 ;)

Post Reply