How do we enable thumb mode in stm32f series when we use embedded c to drive it?Can you explain it in detail as i am a beginner

Question

I want to enable thumb mode in stm32f401re board. the code i had written for it is in embedded c. How do we enable thumb mode in embedded c language. Do we use -mthumb command for it, do we have to add any library prior using that command. Or is there any totally different method.

I searched and found the method only in assembly language. But i want it in embedded c. I used even the -mthumb command but it showed an error.

Answer 1

unsigned int more_fun ( unsigned int );
unsigned int fun ( void )
{
    return(more_fun(0x12345678));
}


$ arm-none-eabi-gcc -O2 -c so.c -o so.o
$ arm-none-eabi-objdump -d so.o

so.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <fun>:
   0:   e92d4010    push    {r4, lr}
   4:   e59f0008    ldr r0, [pc, #8]    ; 14 <fun+0x14>
   8:   ebfffffe    bl  0 <more_fun>
   c:   e8bd4010    pop {r4, lr}
  10:   e12fff1e    bx  lr
  14:   12345678    .word   0x12345678

That is defaulting to arm, looks like armv4, so that should work on non-cortex-ms from armv4 to armv7 (couple of decades).

To get all thumb variants, which will work on your cortex-m4

$ arm-none-eabi-gcc -mthumb -O2 -c so.c -o so.o
$ arm-none-eabi-objdump -d so.o

so.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <fun>:
   0:   b510        push    {r4, lr}
   2:   4803        ldr r0, [pc, #12]   ; (10 <fun+0x10>)
   4:   f7ff fffe   bl  0 <more_fun>
   8:   bc10        pop {r4}
   a:   bc02        pop {r1}
   c:   4708        bx  r1
   e:   46c0        nop         ; (mov r8, r8)
  10:   12345678    .word   0x12345678

add -mthumb, but you are using armv4t, it still works

   a:   bc02        pop {r1}
   c:   4708        bx  r1

Now you can move up to cortex-m0 which will work on all cortex-ms

$ arm-none-eabi-gcc -mcpu=cortex-m0 -O2 -c so.c -o so.o
$ arm-none-eabi-objdump -d so.o

so.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <fun>:
   0:   b510        push    {r4, lr}
   2:   4802        ldr r0, [pc, #8]    ; (c <fun+0xc>)
   4:   f7ff fffe   bl  0 <more_fun>
   8:   bd10        pop {r4, pc}
   a:   46c0        nop         ; (mov r8, r8)
   c:   12345678    .word   0x12345678

the mthumb was not needed but we see it is not arv4t level it is newer

   8:   bd10        pop {r4, pc}

Note we did not need -mthumb, but always check just in case

And then you can go up to what you have if you wish

$ arm-none-eabi-gcc -mcpu=cortex-m4 -O2 -c so.c -o so.o
$ arm-none-eabi-objdump -d so.o

so.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <fun>:
   0:   4801        ldr r0, [pc, #4]    ; (8 <fun+0x8>)
   2:   f7ff bffe   b.w 0 <more_fun>
   6:   bf00        nop
   8:   12345678    .word   0x12345678

okay that is a big disturbing, but I guess because of the additional thumb2 extensions that arm7-m has that armv6-m does not they chose this, they could have done the tail optimization with cortex-m0 or -mthumb as well.

I was hoping for this instead

unsigned int more_fun ( unsigned int );
unsigned int fun ( void )
{
    return(more_fun(0x00001234)+1);
}

Disassembly of section .text:

00000000 <fun>:
   0:   b508        push    {r3, lr}
   2:   f241 2034   movw    r0, #4660   ; 0x1234
   6:   f7ff fffe   bl  0 <more_fun>
   a:   3001        adds    r0, #1

with the 16 bit immediates in two instructions but this one did an ldr, same number of bytes, slower, but whatever both work, I got it to generate one movw...

And then you link these objects together along with your bootstrap and then figure out how to get it on the flash in your mcu.

If all you wanted to know is how to make the compiler generate thumb instructions from C that is easy. If you have C code from some other mcu, then the instruction set is trivial and you may have a significant amount of work as a fair amount of the code has nothing to do with the instruction set but instead the chip which is likely completely incompatible with any other mcu that is not already cortex-m based (and even if cortex-m based if it is not same vendor same family you are still doing a re-write)