ARM bare-metal program compilation -control flash writes

Question

I'm trying to compile some C code to run on an ARMv6 simulator, with FLASH memory starting @ 0x0 and RAM starting at 0x800000. Right now, I can pass binary files off the the simulator just fine...

However, I want the instructions generated to not include any writes to flash memory, and only operate within RAM memory (after copying RAM). Is this possible?

I am using the GNU toolchain to compile.

This is my current linker script:

MEMORY
{
    rom(rx) : ORIGIN = 0x00000000, LENGTH = 0x00800000
    ram(!rx) : ORIGIN = 0x40000000, LENGTH = 0x00800000
    h : ORIGIN = 0x40000000, LENGTH = 0x00400000
}

SECTIONS
{
    .text : { *(.text*) } > rom
    .bss : { *(.bss*) } > ram
    .heap : { *(.heap*) } > h
}

    end = ORIGIN(h) + LENGTH(h);

_stacktop = ORIGIN(ram) + LENGTH(ram);

I do not fully understand what the problem is. Is it not so that you have to deliberately call functions that write to flash. Is the solution not just not to call those functions? — Bart, May 31 '19 at 08:47
So 0x00000000 is the read-only (code) region, 0x800000 is the read-write (data) region. This should be common in almost every bare metal example for arm... — Sean Houlihane, May 31 '19 at 12:11
Did you check this post? https://stackoverflow.com/questions/15137214/how-to-run-code-from-ram-on-arm-architecture — Jose, May 31 '19 at 16:01
@Bart My problem is that when I compile the C code, I'm not sure whether or not there are ARM instructions that write to flash in the simulator. — person314314314, May 31 '19 at 18:42
if you wrote code to do that then yes it will do that. the toolchain is dumb it does what you tell it to do. if you dont want it to happen then dont write code that writes to that address space. — old_timer, May 31 '19 at 21:19
one would hope the simulator would trap these and fault for you in some way as a helpful debug tool. do you have access to the source for the simulator? can you make this modification? real world it just does nothing or if you have an mmu then you can configure it to fault. — old_timer, May 31 '19 at 21:23
It would be useful at this point if you were to include your evidence that this is actually happening together with the code that is causing it. — Clifford, Jun 01 '19 at 07:44

Clifford · Accepted Answer · 2019-06-01T07:52:52.257

1

Your build linker script (normally a .ld file) determines the locations of your device's memory and how the linker sections are mapped to that. Your link map should not include writable sections in read-only memory, that will fail.

[Added after linker script added to question]

You linker script seems unusual in lacking a .data section:

.data : { *(.data) } > ram

Without that it is not clear what the linker will do with static initialised data.

Also your question states that the RAM starts at 0x800000, but the linker script clearly locates it at 0x40000000. Perhaps this misunderstanding of your memory map is leading you to erroneously believe that writes to the ROM region are occurring?

edited Jun 01 '19 at 07:52

answered May 31 '19 at 12:32

Clifford

88,407
13
85
165

Thanks, I included my linker script. I specified the ROM section to not be write-able.However, when I look at the disassembly after being compiled, if my C code includes functions like printf, fprintf, I see writes to flash memory. Is it possible to change that? – person314314314 May 31 '19 at 18:46
you have to write code that doesnt write to invalid address spaces. The toolchain cant prevent that. What the toolchain will do is when it allocates items in memory .text, .data, .bss, it will put those where you ask it to. What the .text does when it executes is your problem. where .text is also your problem but you are asking the tool to put it there. – old_timer May 31 '19 at 21:18
thanks for responding :) What do you mean where .test is is a problem? – person314314314 May 31 '19 at 21:27
@person314314314 what he is saying is that apparent writing to flash is a most likely problem with your code, not the tool chain. – Clifford Jun 01 '19 at 07:31

ARM bare-metal program compilation -control flash writes

1 Answers1