Alternative dso firmware [Application Software Design Entry]

[tormod]

gabonator1:

@gabonator1

this is my build script… the problem will be somewhere else, but thanks for a try
[code]
set CFLAGS=-Wall -Werror -Os -fno-common -mcpu=cortex-m3 -mthumb -msoft-float -MD -std=c99 -Wno-psabi
set LDFLAGS=-nostartfiles -mcpu=cortex-m3 -mthumb -march=armv7 -mfix-cortex-m3-ldrd -msoft-float

rem Build library
!CC! !CFLAGS! -c -Wall -Werror -fpic …/library.c
!CC! !LDFLAGS! -shared -o libbios.so library.o

rem Build example
!CC! !CFLAGS! -S …/main.c
!CC! !CFLAGS! -c …/main.c
!CC! -T …/APP2main.lds !LDFLAGS! -Wl,-dynamic-linker,gloader.1 -Wl,-emain main.o -o !TFILE!_!APP!.elf -lbios -L.
[/code]

I don’t understand why you are using the -march=armv7 option. It should be enough to specify -mcpu=cortex-m3 which already defines the architecture. Also. the architecture for the cortex-m3 used in STM32F103 is armv7-m and not armv7. Possibly your conflicting architecture specification fools the toolchain into allowing ARM instructions.

Disassembly of section .plt:

200050b8 <.plt>:
200050b8: e52de004 push {lr} ; (str lr, [sp, #-4]!)
200050bc: e59fe004 ldr lr, [pc, #4] ; 200050c8 <_ebss+0x18>
200050c0: e08fe00e add lr, pc, lr
200050c4: e5bef008 ldr pc, [lr, #8]!
200050c8: 00000064 .word 0x00000064
200050cc: e28fc600 add ip, pc, #0, 12
200050d0: e28cca00 add ip, ip, #0, 20
200050d4: e5bcf064 ldr pc, [ip, #100]! ; 0x64
[/code]

You can see all instructions in the .plt section are 4 bytes wide, a typical sign of ARM instructions and not Thumb. This is the root of your problem: The toolchain has compiled and labelled this code as ARM code and therefore also calls into it with pair addresses (like 0x200050cc, or 0x200050e0 in your other post).