Confusion with thumb instructions while compiling recipe for cortexm4 CPU

Question

I have an STM32F373 microcontroller and some application in C that use ST HAL library. I need to build this application as recipe from Yocto. Note, that I do not need to run Linux on this MCU, I only need to compile .hex firmware file for cortexm4 CPU. I've created a machine file stm32f373.conf for it:

TARGET_ARCH         = "arm"                                                          
MACHINEOVERRIDES   =. "stm32:stm32f3:stm32f373:"                                     
#TUNE_FEATURES       = "thumb"                                                       
#ARM_INSTRUCTION_SET = "thumb"                                                       
                                                                                                                                                                    
require conf/machine/include/arm/armv7m/tune-cortexm4.inc

But when I try to compile my recipe with this machine, some system packages fail to compile with errors:

arm-oe-linux-gnueabi-gcc  -mcpu=cortex-m4 -march=armv7e-m --sysroot=.../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/recipe-sysroot ../sysdeps/arm/crtn.S -c     -I../include -I.../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/build-arm-oe-linux-gnueabi/csu  -I.../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/build-arm-oe-linux-gnueabi  -I../sysdeps/unix/sysv/linux/arm/le  -I../sysdeps/unix/sysv/linux/arm  -I../sysdeps/arm/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/arm  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/arm/le/nofpu  -I../sysdeps/arm/nofpu  -I../sysdeps/ieee754/soft-fp  -I../sysdeps/arm/le  -I../sysdeps/arm/include -I../sysdeps/arm  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem .../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/../../lib/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/11.4.0/include -isystem .../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/../../lib/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/11.4.0/include-fixed -isystem .../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/recipe-sysroot/usr/include -D_LIBC_REENTRANT -include .../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/build-arm-oe-linux-gnueabi/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h  -DPIC     -DTOP_NAMESPACE=glibc -DASSEMBLER -I.../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/build-arm-oe-linux-gnueabi/csu/. -g -fdebug-prefix-map=.../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0=/usr/src/debug/glibc/2.35-r0 -fdebug-prefix-map=.../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/recipe-sysroot= -fdebug-prefix-map=.../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/recipe-sysroot-native= -Werror=undef -Wa,--noexecstack   -o .../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/build-arm-oe-linux-gnueabi/csu/crtn.o -MD -MP -MF .../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/build-arm-oe-linux-gnueabi/csu/crtn.o.dt -MT .../yocto-builder/build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/build-arm-oe-linux-gnueabi/csu/crtn.o
...
mv -f .../build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/build-arm-oe-linux-gnueabi/csu/stamp.oT .../build/tmp-stm32f373/work/cortexm4-oe-linux-gnueabi/glibc/2.35-r0/build-arm-oe-linux-gnueabi/csu/stamp.o
| ../sysdeps/arm/sysdep.h: Assembler messages:
| ../sysdeps/arm/sysdep.h:144: Error: selected processor does not support ARM opcodes
| ../sysdeps/arm/crti.S:64: Error: attempt to use an ARM instruction on a Thumb-only processor -- `ldr r3,.LGOT'
| ../sysdeps/arm/crti.S:65: Error: attempt to use an ARM instruction on a Thumb-only processor -- `ldr r2,.LGOT+4'
| ../sysdeps/arm/crti.S:67: Error: attempt to use an ARM instruction on a Thumb-only processor -- `add r3,pc,r3'
| ../sysdeps/arm/crti.S:68: Error: attempt to use an ARM instruction on a Thumb-only processor -- `ldr r2,[r3,r2]'
| ../sysdeps/arm/crti.S:69: Error: attempt to use an ARM instruction on a Thumb-only processor -- `cmp r2,#0'
| ../sysdeps/arm/crti.S:70: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bxeq lr'
| ../sysdeps/arm/crti.S:71: Error: attempt to use an ARM instruction on a Thumb-only processor -- `b __gmon_start__'
| ../sysdeps/arm/crti.S:84: Error: attempt to use an ARM instruction on a Thumb-only processor -- `push {r3,lr}'
| ../sysdeps/arm/crti.S:86: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bl call_weak_fn'
| ../sysdeps/arm/crti.S:97: Error: attempt to use an ARM instruction on a Thumb-only processor -- `push {r3,lr}'

I've tried to enable thumb by ARM_INSTRUCTION_SET = "thumb", as in commented code, but it changes nothing. I've also tried set this variable in my application recipe, and it has no effect neither. I've also tried to enable it by TUNE_FEATURES = "thumb", but than I get an error:

ERROR:  OE-core's config sanity checker detected a potential misconfiguration.
    Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
    Following is the list of potential problems / advisories:

    Error, the PACKAGE_ARCHS variable (all any noarch armv7em cortexm4 stm32f373) for DEFAULTTUNE (cortexm4) does not contain TUNE_PKGARCH (cortexm4t2).

I use kirkstone Yocto release, host is x86_64 machine.

How to compile single application recipe for cortexm4 CPU with Yocto?

Answer 1

There are three things needed to define a compiler.

1. The ISA or target assembler.
2. The OS (or 'bare metal').
3. The library.

There are some 'C' features such as floating point and double that require utility routines. In turn, there may be error cases which emit a 'signal' such as 'SIGFPE', etc. The compiler support library, 'libgcc' may make calls to the linux kernel and/or rely on features of the linux kernel in the Yocto tool set.

IF you insist on use the yocto/open embedded tooling, you MUST build with -ffreestanding. The other items is setting up the 'C' environment. There are routines to set a stack, clear 'bss' and initialize data. Some functions like 'C++' static constructors must be run before main.

You must also remove options like --sysroot as there is not a root file system which can be used. Ie, you can not link to Yocto libraries and/or include Yocto header files. The compiler undefines 'HOSTED' and the compiler 'C' libraries will be conditionally set NOT to use Linux system calls and features if and only if you use -ffreestanding.

It is much simpler to get an 'arm-none-eabi' toolsuite. Where ever your advice to use the yocto compiler comes from, is from technically wanting people. While it is possible, it is an exercise in frustration. I would get the arm-none-eabi compiler and produce the '.hex' file. After it is building, you can try to substitute the yocto gcc. Then and only then would I try to get the bitbake stuff working. You will have to override many assumptions in bitbake files.

sysdeps/arm/crti.S

This is the startup library and it is attempting to use assembler constructed for 'arm' CPUs and not thumb. Note that compiling with -ffreestanding will often result in undefined symbols. These can be mathematical support routines such as 64bit division, etc.

You can find a list of ways to deal with this here.