STM32L4 QSPI flash memory mapped

[Lukasz Przenioslo]

Posted on June 16, 2018 at 14:32

Hello there,

In the device I am developing on STM32L452 I foresee running out of flash memory, as the application code is getting bigger. The maximum flash amount for this chip is 512 KB (which I use). I thought I could maybe use the 256 KB version only to store the bootloader and add an additional NOR flash QSPI memory (ie. 16 Mbit) for storing the whole application code.

The thing is, I am not sure either this approach is possible. Looking at the L4 examples from STM32Cube_FW_L4_V1.8.0 memory mapped mode seems to allow reading the external flash in code, as if it was internal. But is it possible to boot from it and run on it?

I would appreciate all help.

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

[Tesla DeLorean]

Posted on June 16, 2018 at 15:10

>>

But is it possible to boot from it and run on it?

Booting tends to be an issue because the clocks, pins, and buses need to be configured, and that all tends to be board/design specific.

You might also want to quantify how fast different regions of memory are. Where there is a disparity you might want to put library routines in the faster memory. Last did that in RealView with .DEF files, but would suspect similar methods could be achieve with current linkers, or using jump tables to define entry points.

[Lukasz Przenioslo]

Posted on June 16, 2018 at 15:19

Thanks for answer,

I thought that the qspi config could be done in bootloader prior to jump to

the new address maybe?

You approach seems a bit too low level. I dont mind being in the slow

external flash all the time, the system doesnt have any real REAL time

routines like motor driving. Being able to simply run all code from qspi

without any function cherry picking would be convienient. Do you think

that would work?

[Tesla DeLorean]

Posted on June 16, 2018 at 16:25

>>I thought that the qspi config could be done in bootloader prior to jump to the new address maybe?

Your own boot loader can configure your hardware as built, and can validate and jump to code wherever.

The DISCO boards have 16MB, 32MB and 64MB (512Mbit) type parts, more personal mileage on the F7

STM32Cube_FW_L4_V1.12.0 might have more examples