How do i need to create .bin file for an QSPI memory?

[DK.7]

I am a beginner and I do according to this video "External Qaspi Loader How to - 05 - Qspi Driver Coding" https://youtu.be/XqCq0xtQmbI I uploaded the project "EXTERNAL QSPI Loader" to stm and now question about .bin file

How to create a data file to be stored in the Flash memory,

which can be a binary file or .hex?

For example, I have a project "Hello World" and I want to upload it to external QSPI memory.

I need as usual to create a project "Hello world" and just indicate in the stm32CubeIDE settings to create a .bin

Or I need to make some additional settings for my "Hello world" project like, MPU configuration!?!

And the resulting file, to program Quad-SPI Flash memory using the ST-LINK utility...

[Tesla DeLorean]

STM32 Cube Programmer can take .BIN, .HEX files as input

.BIN files can be created via tools like objcopy, fromelf or srecords

The External Loader files with the .STLDR extension are .ELF files that basically load like DLL files into the STM32's RAM providing support for your hardware, pin, wiring and chip combos.

To run code out of the QSPI memory you'd need some Internal Flash based code to bring up the QSPI memory and transfer control to code in there. This can be part of the app, or as a loader that calls an app that resides completely in the QSPI memory.

[DK.7]

Thanks for the answer!

I have a board from "Weactstudio" https://aliexpress.ru/item/1005001475058305.html

And they posted on Github an example "02-extm_boot" https://github.com/WeActStudio/MiniSTM32H7xx/tree/master/SDK/HAL/STM32H750/02-ExtMem_Boot

which run the program on 8Mb qspi flash, this routine is QSPI Bootloader, App Addr:0x90000000

For understanding how it works, I tried to upload a simple "Blink" on external QSPI flash...

I uploaded a code "02-extmem_boot" to the internal Flash memory which start from 0x0800000

And also uploaded the "Blink" with "STM32CubeProgrammer" to fed to him the .bin file which uploaded from address 0x90000000.

But it dosn't work!

Could you tell me what I'm doing wrong?

[Tesla DeLorean]

>>Could you tell me what I'm doing wrong?

Hard to say, use a debugger, step into the loader code, and then thru the transition to your application code.

Make sure the vector table on the "External Blink" at does reflect the 0x90000000 basis, and that the SCB->VTOR settings in SystemInit() do actually set the address to the same 0x90000000 address.

Review the .MAP and .LST (listing/disassembly) of the "External Blink" are consistent with expectations for an image built to execute from QSPI

[DK.7]

>>Make sure the vector table on the "External Blink" at does reflect the 0x90000000...

The question is how to implement an application for testing "ExtMem_Boot"

I have a simple code in file main.c of my testing application.

   / * User Code Begin While */
   While (1)
   {
     / * User Code end While */
 
     / * User Code Begin 3 */
Counter ++;
Printf ("Hi from QSPI and Counter = \%D \ N", Counter);
Hal_gpio_togglepin (PE3_GPIO_PORT, PE3_PIN);
Hal_Delay (500);
   }
   / * User Code end 3 */
}

And also performed a few steps:

1. Reset RCC register in SystemInit function (file system_stm32h750xx.c) RCC->CFGR = 0;

2. Relocate Vector Table in my case it to QSPI_BASE = 0x90000000 SCB->VTOR = QSPIBASE;

3. Linker script configured according size of my chip, see screen.

QUESTION: Is this enough for the correct launch of my testing application from the external QSPI?

[Tesla DeLorean · Accepted solution]

From the application side I would avoid reseting or touching the RCC for the most part. Specifically you really don't want to be tearing down the clock sources, PLLs, or reconfiguring or touching anything related to the QSPI.

For example not DeInit'ing the GPIO bank(s)

Contractually you want ALL the system bring-up on the Boot Loader side, ie the clocks the PLL, the system critical pins, etc. The things you will use all the time, and would facilitate system updates and recovery.

You don't have to bring up UART, SPI, I2C that the loader doesn't use. And generally you don't want a lot of interrupts, as these will complicate the hand-over.

The SystemInit() on the App side needs to be relatively lean, perhaps enable the FPU, and assign the new operational SCB->VTOR

[Tesla DeLorean]

Yes, the Linker Script (.LD) looks to be Ok,

The origin has to be aligned to a 512 byte boundary, but can be deeper into the QSPI provided the Loader and App have a consistent understanding of where it is.

Here I use a symbolic link to set the VTOR, and I also load the SP in my Reset_Handler, as this also reduces the complexity of the hand-over, and compiler issues related to changing the stack pointer, and then referencing local/auto variables.

[DK.7]

Thanks for your comments, finally everything worked!

And now I have a new problem, If the application is implemented using a FreeRTOS!

If I change the linker script, the application is not compiled, see screen.

How to configure FreeRTOS application for external boot by QSPI?