How to execute code from external flash on STM32F407

[Daniel Collado]

Posted on June 15, 2018 at 12:15

Hi, I have read the AN4852 application note explaining how to program an external QSPI flash using the built-in UART bootloader. However it does not tell how to execute afterwards the code saved in the external flash on the microcontroller. Does the microcontroller somehow have to read the code and copy it into internal flash or how could it be done?

#external-flash #code #stm32f407 #execute

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[waclawek.jan]

Posted on June 15, 2018 at 12:46

The 'classic' 'F4xx don't have facility to run code from QSPI, so you'd need either to copy it into internal FLASH or internal RAM (except the CCM RAM) and run it from there.

Newer families, such as the 'L4 and 'F7, and the upper-end and lower-end 'F4, have a QSPI controller which can be part of the memory map and code can be run directly from there.

JW

[Daniel Collado]

Posted on June 15, 2018 at 13:18

Ok, thank you. And is there any kind of 'easy' way of copying the code into internal flash?

[Tesla DeLorean]

Posted on June 15, 2018 at 15:17

The 'easier' way would be to memcpy() it to RAM and jump to it there.

The QSPI support in some of the F4 and F7 parts maps the external memory into the address space of the processor (0x90000000), and from there you can jump to it like any other code, and execute-in-place (XIP)

External memory on the F4 parts is not remotely fast or cached.

On the F42x/F43x parts you can use SDRAM, as I recall thats about 6x slower to access than internal SRAM.

It is not that 'hard' to erase/write internal FLASH, one could certainly construct a 'memcpy' type function to achieve it.

[Daniel Collado]

Posted on June 18, 2018 at 09:19

So there is not a memcpy() function to copy code into flash but just using the custom functions from HAL to do so. I've read that first the flash must be unlocked before erasing or writing to it. Why is this? Just curious.

Another issue, my binary file would be a .elf instead of a .bin, does it matter? Because I've seen that .bin files are purely binary but .elf files have more things such sections, symbols, relocateable table for address offsets and so.

[waclawek.jan]

Posted on June 18, 2018 at 10:10

So there is not a memcpy() function to copy code into flash but just using the custom functions from HAL to do so.

You can write your own...

flash must be unlocked before erasing or writing to it. Why is this?

This is some sort of a safeguard, so that it's less likely that some runaway piece of code would make things worse by overwriting unintentionally the FLASH.

Another issue, my binary file would be a .elf instead of a .bin, does it matter?

Extract the relevant binary from .elf using objcopy, e.g. (depending on your particular toolchain)

'[path to toolchain]\bin\arm-none-eabi-objcopy' -O binary main.elf main.bin

JW

[Daniel Collado]

Posted on June 25, 2018 at 09:31

I've been studying how the bootloader of this uC works and it needs something which sends the commands and data through UART, from which I understand that the uC itself cannot autoboot and copy the code by itself. I was thinking about putting a PIC and make this send the data from a FRAM to the STM, but by doing this the system will depend on the flash of the PIC instead of the FRAM. Is there any approach on autobooting the STM?