How to putg all the code into RAM

[SBosc]

Good morning,

I'm writing a bootloader and I need to put all the code in the RAM and execute from it (the microcontroller is a STM32F733).

The code is already working correctly from the flash.

How can I move it into the RAM?

Thanks in advance

[Diane POMABIA]

Hi @SBosc​,

What Type of IDE are you using ( IAR, STM32CubeIde or Keil )?

Regards

Diane

[SBosc]

Hi @Diane POMABIA​ ,

I'm using STM32CubeIde.

It seems that simply using the automatically generated linker script for RAM relocation is not enough...

Maybe not all the code is automatically copied by the startup routine?

Regards

Simone

[Diane POMABIA]

@SBosc​ 

yes, In system_stm32f7xx.c , you have also to uncomment "#define VECT_TAB_SRAM " and be sure that in your linker, you have selected correct linker script.

Regards

Diane

[Tesla DeLorean]

Depends on the build options, most of the code can be relative if contained in one region.

You'll need to fixup the Vector Table content, as those have absolute addresses. And point SCB->VTOR at the appropriate location. Relocation shouldn't be unduly hard.

You'll likely need to at least walk the reset of the generated code to make sure there aren't any absolute addresses lurking, function pointers and the like.

[SBosc]

@Diane POMABIA​ 

I've set the VECT_TAB_SRAM using the preprocessor.

It works when the execution is perfomed with the debugger connected (and continues to work even if I unplug the debugger on the fly) but it won't start if I try to boot without the debugger

@Community member​ 

Maybe you're right.

I think that there's a chance that program halts when an interrupt is generated.

I didn't remapped the vector addresses to the "new" RAM addresses!

There's a way to get the RAM addresses automatically? Or have I to rebuild "manually" the vector table?

[Tesla DeLorean]

Well the linker script defines where the code is expected to be parked, and the SystemInit() code has some dumb hard-coded method using defines rather than simply pulling the vector tables address symbolicly, and setting it into SCB->VTOR. If ST had done that from the outset you'd only need to change the base build address in ONE place.

>>There's a way to get the RAM addresses automatically?

Not sure how that'd work the linker frosts a particular build address because the content within this .ELF variant is expected to live at a fixed address in ROM. You can change that to RAM.

Automatic vs Manual, the processor doesn't do it, you'll likely need to automate the task yourself.

If the content starts in ROM/FLASH and you want to copy a runnable instance to RAM, you'd do the memcpy(), put the RAM image at a 512-byte aligned address, and then enumerate thru the 32-bit array that is the vector table, rebasing the address, ie subtract 0x08000000 then adding 0x20000000, if you use the base of RAM and it's unconflicted from other usage. Set the SCB->VTOR to the base address

Enter thru a control point, like the reset handler, and watch SystemInit() is a aware of the memory address it's running from, or leaves SCB->VTOR alone.

[Pavel A.]

As @Community member​ wrote, just set the VTOR.

The easiest way: don't fiddle with SystemInit(). Instead, in your main() just add this:

extern uint32_t g_pfnVectors[];
  SCB->VTOR = (uint32_t)g_pfnVectors;

 and use the linker script for RAM.

Now the question is, where you want to store this image: in the internal flash? some external memory?

[Tesla DeLorean]

>but it won't start if I try to boot without the debugger

Yes, because if the debugger pushes the data into RAM, this isn't going to magically happen at power-up / reset on a free-standing part.

The MCU maps based on the BOOT pins and Option Byte settings. At power-up you're going to need to run from FLASH, at least initially to move the content to RAM

[Tesla DeLorean]

This might be less helpful if the image is expected to reside in FLASH and RAM interoperably / interchangeably .

Also the RAM for variables/statics need to move to accommodate the firmware image.

Assumption here is that during updates the code needs to run from RAM so the FLASH stalling issue can be avoided.

When I copy code to RAM is typically a smaller self-contained blob, and it doesn't call other functions beyond the scope of the blob.