As an exercise, I want to let STM32F103 execute from internal SRAM. The idea is to write some THUMB assembly by hand, assemble it with arm-none-eabi-as, load the machine code into SRAM with OpenOCD's mwh instruction, set PC to the beginning of SRAM with reg pc 0x20000000, and finally step a few times.
Here is the assembly code I want to execute. It's basically a pointless loop.
# main.S
.thumb
.syntax unified
mov r0, #40
mov r1, #2
add r2, r0, r1
mvn r0, #0x20000000
bx r0
I need to get the machine code so that I can load it into SRAM, but the disassembler output doesn't seem to be right.
$ arm-none-eabi-as -mthumb -mcpu=cortex-m3 -o main.o main.S
$ arm-none-eabi-objdump -d -m armv7 main.o
main.o: file format elf32-littlearm
Disassembly of section .text:
00000000 <.text>:
0: f04f 0028 mov.w r0, #40 ; 0x28
4: f04f 0102 mov.w r1, #2
8: eb00 0201 add.w r2, r0, r1
c: f06f 5000 mvn.w r0, #536870912 ; 0x20000000
10: 4700 bx r0
Shouldn't the THUMB instructions be 16-bits in length? The machine code I got take 4 bytes per instruction.
The STM32F103 is cortex-m3 based. You need to start with the st document where it says that then go to arms website get the cortex-m3 technical reference manual. In that it tells you this is based on the armv7-m architecture and so you get the architectural reference manual. And then you can BEGIN to start programming.
Running from flash the normal way uses a vector table, running from ram can mean that depending on the boot pins, but if you want to download the program using the debugger you are on the right path you just got stuck or stopped before finishing.
You specified unified syntax and perhaps on the command line cortex-m3? or armv7-m? So you ended up with thumb2 extensions they are two 16 bit halves as documented by ARM (armv7-m architectural reference manual shows you all the instructions). They are variable length the first one is decoded the second one is just operands. The non-thumb2 are all 16 bit, the bl/blx were/are two separate 16 bit instructions, but the cortex-ms want those to be back to back where on prior cores you could actually separate them to demonstrate they were truly two different instructions.
so for example
The 16 bit "all thumb variant" encoding is with flags only so you have to put adds; if gnu assembler and you specified unified syntax, which most folks are going to tell you to do, I do not personally. Just so you know:
so
Just to warn you in case you fall into that trap. And do not you just love that the disassembler uses adds.
Anyway. So these are fine, these are
Like add the 16 bit encoding of mov is with flags so
and we know about add now
The mvn makes no sense you want to branch to 0x20000000 two things, first you want 0x20000000 not 0xDFFFFFFF so try this
Second this is a cortex-m so you can't bx to an even address that is how you switch to arm mode but this processor does not do that so you will fault. You need the lsbit set. So try this
With gnu assembler the ldr equals thing will pick the most efficient (smallest instruction) solution if it can otherwise it pulls from the pool.
Or you could do this and not use the pool
This makes my skin crawl because you want to orr not add, but this would make it a halfword shorter if that matters:
Then you need to link. But...
Link without a linker script to make this quick
Open two windows, in one start openocd to connect to the board/chip
In the other
When you get the openocd prompt assuming that all worked
Or you can resume 0x20000001 since that feels better but the tool is fine either way. Now
Being an stm32 and being all thumb variant instructions this example will work on any stm32 I have heard of so far.
What you will see is that r0 it will increment, the human time between resuming and halting again it will count many times times you can see the number change to see that the program is running.
If you want to then put it in flash, assuming the blue pill (this is a blue pill right?) does not have a write protected flash which some do, but you can easily remove that (will let you figure that out, is not necessarily easy, pro tip a complete power cycle is involved at some point).
The reset vector needs to be address of handler ORRED with one. And the vector table needs to be at 0x08000000 (or 0x00000000 but you will end up wanting 0x08000000 or 0x02000000 for some not this one, 0x08000000 for this one, read the docs).
In the telnet into openocd
And now it is programmed in flash so if you power off then on that is what it runs.
openocd will end with something like this
then the telnet session
If you want the flash to reset into ram you can do that
Power cycles it should ideally crash/fault but if you use openocd to put something in ram like we did before
but a power cycle
Yeah, not happy as expected/desired.
Note _start comes from an ENTRY(_start) in a default linker script, it is not special nor really hard-coded into the tools (nor is main for gcc, that comes from a default bootstrap).
So you can do this
so.s
so.ld
and the _start warning goes away. Note that the section names you create in the linker script (hello in this case) do not have to be ram, rom, flash, etc they can be what you want and yes you could do this with a linker script but without a MEMORY section in the file and only SECTION.
If you choose to
openocd can read elf files and some others but a raw memory image like that you have to specify the address otherwise you might get 0x00000000 or who knows what
If/when you get some nucleo boards, you can simply copy the bin file to the virtual thumb drive and it will load it into the target mcu for you and the virtual drive will sort of reload or will reload and show a FAIL.TXT if it did not work one way that happens is if you link for 0x00000000 instead of 0x08000000. You can't load for sram that way though, just flash. But I assume you have a blue pill not a nucleo board.
That is the long answer.
Short answer
Those are thumb2 extensions they are two halfwords in size. See the armv7-m architectural reference manual for the instruction descriptions. They are perfectly fine for this chip.
You probably want to use load_image not mwh on openocd, but mwh will work if you get your halfwords in the right order.
You ideally want to link although as written your code or mine is position independent so arguably you could just extract the instructions and use mwh.
The chip has a boot from sram mode which would/should use a vector table not just launch into instructions, you would need to get the boot pins set right and use something like openocd to load the program into ram, then reset (not power cycle).
MVN move negative or negate is not the right instruction here and you need the lsbit set before using bx so you want 0x20000001 in the register, something like
for gnu assembler, or
but that is for armv7-m, for cortex-m0, m0+ some of the -m8s you can't use those instructions they will not work.
So use the ldr = pseudo instruction or load from the pool manually, or load 0x2 or 0x20 or something like that then shift it and load another register with 1 and orr it or use add (yuck).
Edit
If it cannot generate a single instruction then it will generate a pc relative load and put the variable in a literal pool, somewhere after a branch if it can find one.
But you can do this yourself too
Not unusual to have the C compiler do this and put it at the end of the function.
I did not build that for thumb/cortex-m but that is fine it would do the same thing. But, saying that:
Since I have a rough idea of what immediates you can use for the various arm instruction sets. Likewise
By using the ldr = thing gnu assembler will pick the optimal instruction. This is not supported by all arm assemblers (assembly language is defined by the tool not the target), and not all will choose the optimal instruction some may always generate the pc-relative ldr if they recognize the syntax at all.
It is somewhat meant to be used to get the address of a label for example
being in another segment it can't resolve this at assembly time so it leaves a placeholder for the linker
Or
even in the same segment
If you let the tools do the work though
You do not need to orr in the lsbit, the tool does it for you
These are all or mostly cases of the literal pool being used to help out with an instruction set like this that is somewhat fixed in length so has a limit on immediate values.
Sometimes you can help gnu assembler as to where to put the pool data
but if I
So
Means at link time or sometime load the address of something into r0. Labels are just addresses which are just values/numbers so
Means the same thing the label is instead the value itself so give me the address of that label which is 0x12345678 and put that in r0, so it is an interesting extension of that notion that gas or someone thought of, probably arms assembler, I do not remember then others adopted it as well or improved upon it or whatever. Note if you want to do it yourself you do this
because something is a label which is an address which is a value you do not put the equals there, the equals is just for the ldr instruction. Same as the vector table:
And lastly you can do one of these to get the function address correct for so called thumb interwork
Can use .thumb_func if in thumb you can use .type label,%function both in arm mode and thumb mode and you can see that it generates the proper thumb address in the vector table, but where neither were used the broken label is not generated correctly so that vector would fault on a cortex-m.
Some folks sadly do this:
to try to fix that rather than using the tool as intended. Other assembly languages for arm/thumb meaning other tools (ARM, Kiel, etc) have their own syntax and rules this is limited to gnu assembler.
Also note how much of this answer was just command line stuff, I examined the output of the tool and manipulated it until I got what I wanted, did not have to load and run code to see what was going on. Just use the tools.
Edit 2
Reading the rest of your question in the comment
Putting the .word at offset 6 would be an alignment fault for an ldr so they need to pad it to put it at a word aligned address.
By now you should have downloaded the armv7-m architectural reference manual from ARM's website or elsewhere. And you can see at least in the one I am looking at (these are constantly evolving documents) the T1 encoding
and further down
and
The offset (immediate) encoded in the instruction is the number of words relative to the pc. The pc is "two ahead" or address of the instruction plus 4 so for the ldr r0 instruction
8 - 4 = 4; 4>>2 = 1 so 1 word away from the pc, instruction 0x48xx the xx is 0x4801 to indicate one word. Here again the alignment to use this instruction.
So what if we
that seems broken
When you see all of the pseudo code, then a pc of 6 in this case
Then continuing to read the documentation to understand the pseudo code
so 0x6 & 0xFFFFFFFC = 4. 8 - 4 = 4; 4>>2 = 1; so 0x4801.
If we force the thumb2 instruction
It still aligns probably to save us from faults the thumb2 version can reach odd values
Note the 4 at the end of the instruction that is pc + 4, but what if we tried to do this: