2018-06-16 05:32 AM
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.2018-06-16 06:10 AM
>>
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.
2018-06-16 08:19 AM
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?
2018-06-16 09:25 AM
>>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
2018-06-16 09:28 AM
Yes, I meant my own bootloader- that would be the only application residing
in stm32 internal flash.
Maybe my question should be rephrased- is it possible to not only read from
qspi flash, but also run code from it? If I understand correctly from what
you have said, it is?
2018-06-16 09:55 AM
You should be able to XIP (Execute-In-Place)
STM32Cube_FW_L4_V1.12.0\Projects\32L496GDISCOVERY\Examples\QSPI\QSPI_ExecuteInPlace
2018-06-16 10:14 AM
This is what I was looking for.
I am looking at this example now. I understand how is the memory configured but I cannot figure out how does the compiler knows that the code from case 5 has to placed in the external flash?
case 4: if(StatusMatch != 0) { qspi_addr += size; flash_addr += size; /* Check if a new page writing is needed */ if (qspi_addr < max_size) { /* Update the remaining size if it is less than the page size */ if ((qspi_addr + size) > max_size) { size = max_size - qspi_addr; } step = 2; } else { StatusMatch = 0; RxCplt = 0; /* Configure Volatile Configuration register (with new dummy cycles) */ QSPI_DummyCyclesCfg(&QSPIHandle); /* Reading Sequence ------------------------------------------------ */ sCommand.Instruction = QUAD_INOUT_FAST_READ_CMD; sCommand.DummyCycles = DUMMY_CLOCK_CYCLES_READ_QUAD; sMemMappedCfg.TimeOutActivation = QSPI_TIMEOUT_COUNTER_DISABLE; if (HAL_QSPI_MemoryMapped(&QSPIHandle, &sCommand, &sMemMappedCfg) != HAL_OK) { Error_Handler(); } step++; } } break; case 5: /* Execute the code from QSPI memory ------------------------------- */ GpioToggle(); break; default : Error_Handler(); } }}2018-06-16 10:19 AM
The linker places the the GpioToggle() function in QSPI (via scatter file and &sharppragma in Keil)
The ST-LINK Utilities or Keil Flash Algorithm will burn the compiled code into Internal FLASH and QSPI
2018-06-16 10:48 AM
I have just looked up the linker script, there is indeed the additional section for qspi:
/* Specify the memory areas */ MEMORY { FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 1024K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 96K QSPI (xrw) : ORIGIN = 0x90000000, LENGTH = 1024K }So as you said, I can configure the ST-LINK to burn the external flash with code. Do you know either this code will be debugable as well (using ST-LINK or J-LINK)?
Looking at the architecture side, is it true to say that the bootloader placed in the internal flash is qspi agnostic from linker point of view, but uses qspi in terms of configuration and jumping? Also, the application code placed in the external flash is qspi agnostic in terms of peripheral usage in code (cannot touch those pins) but has to be configured correctly in the linker?