Very basic assembly fails on ARM Cortex-M3 (STM32F103VE)

[oys_mo]

Posted on December 11, 2010 at 01:33

Very basic assembly fails on ARM Cortex-M3 (STM32F103VE)

[Tesla DeLorean]

Posted on May 17, 2011 at 14:18

Yes, there probably is some clutter in there, I tried to trim it down. Plus, I haven't built it in GNU, it was a quick cut-n-paste job for illustration, thus the ''something like this'' disclaimer. Other multiple definition issues might come up depending on what you link it against, it was constructed so it should be able to be the only object/library in the project. Basically you should be able to get down to one .S file, and then use the linker and it's script to place the code/stack into specific memory locations for the STM32, ie FLASH at 0x08000000 and RAM at 0x20000000, and stack at 0x2000xxxx somewhere. GNU usually puts it at the top-of-ram, so say 0x20005000 for a 20KB RAM part.

The vectors need to be placed in the front by the linker, so that when the processor starts up it can locate the code it needs to execute. Other .section stuff relates to ELF sections and flags.

[Tesla DeLorean]

Posted on May 17, 2011 at 14:18

Well to be honest, my code does assemble and link properly with a default install of WinARM\GNU

C:\WinARM\examples\STM32_ASM>make all arm-eabi-gcc -mcpu=cortex-m3 -mthumb -Wall -g -Os -c  -o test.o test.s arm-eabi-gcc -Wl,--gc-sections,-Map=test.elf.map,-cref,-u,Reset_Handler -I . -I lib/inc -L lib -T stm32.ld test.o  --output test.elf arm-eabi-objcopy -O binary test.elf test.bin arm-eabi-objdump -h -S -C -D -M force-thumb test.elf > test.lss Seem to me you are assembling and/or linking it wrong if you are getting errors. Or a matter of ensuring all the libraries are pathed correctly. Separate files would be assembled one at a time, and then linked to produce the final object file. Attached is the entire project with a makefile, and the resultant objects. The final binary is 44 bytes.

[Tesla DeLorean]

Posted on May 17, 2011 at 14:18

progbits is a designation within the ELF file of a section that actual contains data/code of the application, and not debug, comments or other extraneous content.

Some of the size, type, and extended section fields are probably overly verbose or unnecessary. If understanding what is critical, and is important, then referring to suitable documentation might be in order. GNU is not my assembler of choice, I've cobbled this together from some other assorted pieces I have to make a fairly minimalistic example. I think it could be simplified further with some effort. To figure out what is critical, and what the side-effects and consequences of changing thing are, I would start by tweaking or removing things to the point where it breaks and back-track from there. Referring to the documentation, and examining the resultant object/binary along the way. To understand what GCC does in building and linking, and pulling together a working CPU/C environment you should look at the startup.s crt.s or whatever it is using.

[oys_mo]

Posted on May 17, 2011 at 14:18

Thanks again, the code works perfectly fine as long as I don't split up the source. I think the linker gets the ordering wrong. It could probably be fixed in the linker script, but to be honest I'm not really going to need it. The default linker script is complex, and I don't feel like messing with it for a small issue like this. For now I'll just .include the files to produce one single buildable source file. That way the linker can't get it wrong.

I'll keep on reading, and thanks to you I can finally have some fun learning this stuff 🙂 I definitely owe you one! Attached is one cookie 🙂