cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L4 QSPI flash memory mapped

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.
8 REPLIES 8
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.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
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?

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

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on June 16, 2018 at 16:28

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?

Posted on June 16, 2018 at 16:55

You should be able to XIP (Execute-In-Place)

STM32Cube_FW_L4_V1.12.0\Projects\32L496GDISCOVERY\Examples\QSPI\QSPI_ExecuteInPlace

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on June 16, 2018 at 17:14

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();

    }

  }

}
Posted on June 16, 2018 at 17:19

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

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on June 16, 2018 at 17:48

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?