I'm working with a freescale FRDM-MKL25Z4 development board, writing some minimal code. I find that the simulator and the development board seem to disagree on the behavior. also in my disassembly window I often get different disassembly for the same instruction.
memcpy: 0x00000292 B5B0 DCW 0xB5B0 << why isn't this a PUSH? 0x00000294 B089 DCW 0xB089 0x00000296 4613 DCW 0x4613 ... 0x000002DC BDB0 DCW 0xBDB0
memset: 0x000002DE B5B0 PUSH {r4-r5,r7,lr} <<why is it PUSH here? 0x000002E0 B088 SUB sp,sp,#0x20
any help would be appreciated.
DCW is irrelevant - the presentation doesn't interfere with the simulators ability to run code.
A processor do not care if the assembler file thinks a byte is part of data or part of code. When a jump goes to a specific address, the processor will try to decode the data at that address as code.
So if your code jumps to memcpy(), then the simulator will perform as it should. And in that case, it should also disassemble that block of data as code since it understands from the PC that it is expected to be code.
This is the code at the reset vector:
LR:0xFFFF_FFFF R7:0x0000_0000
0x000001E8 B580 DCW 0xB580 << Should set lr to the value in r7
pc gets incremented that is all.
however if it is ran here:
0x000002E0 B580 PUSH {r7,lr} << well I get a hard reset but its diffrent results for the same input.
I upload my elf to here. It blinkys my frdm-kl25z three very bright colors.
drive.google.com/.../view
Your stack alignment is screwed up, you can't use 0x20002FFF, it needs to be 0x20003000, it will decrement from there. A lot of linker scripts have this kind of broken definition.
Thanks that's very useful! I made the change.