Can external loader running on an STM32F030C8 be run from flash, or must external loaders always run from RAM

[RMurt.3]

I am using an STM32f030C8 with External Flash (W25W128) Via SPI, and want to program the extern flash with sound data using STMcubeprogrammer.

I found an excellent article (https://community.st.com/s/article/how-to-add-your-spi-flash-into-the-stm32cubeprogrammer-external-loader-part1) that used a RAM based approach.

My question is can external loaders be a FLASH based program, and will STMcubeprogrammer load the external loader to allow programming of the extern Flash and then after that load the CPU flash with the real application code ?

[Pavel A.]

External loaders can run only from RAM, simply because the host (CubeProgrammer) won't load it anywhere else.

You can place your own code that enables and writes external flash where you want.

[Andreas Bolsch]

Why would anybody want to store an external loader in target's flash? This would be a waste of precious flash in the target (if retained permanently) or require to erase it after use before flashing the actual application (an additional time consuming program/verify/erase cycle, and flash wearout). Whereas uploading it to RAM is fast, RAM isn't used by anything else at that moment, and there's no need to erase anything after use. So what???

[RMurt.3]

Thanks everyone for clarifying what's expected, its very easy to go down a rabbit hole in completely the wrong direction i.e. developing a flash based tool only to find later that it will not work with the tool sets as expected.

I followed the example at top of page, and it looks like I need to put the default generated Stm32CubeMx project on a bit of a diet. - Currently overflowing the RAM segment by about 4k.

Looks like I'll have to jump into the map file and see what it has included that I did not expect 🙂

I included the linker output in case there is an obvious error there.

make -j4 all 

arm-none-eabi-gcc "../Src/Loader_Src.c" -mcpu=cortex-m0 -std=gnu11 -g3 -DDEBUG -DUSE_HAL_DRIVER -DSTM32F030x8 -c -I../Inc -I../Drivers/STM32F0xx_HAL_Driver/Inc -I../Drivers/STM32F0xx_HAL_Driver/Inc/Legacy -I../Drivers/CMSIS/Device/ST/STM32F0xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -MMD -MP -MF"Src/Loader_Src.d" -MT"Src/Loader_Src.o" --specs=nano.specs -mfloat-abi=soft -mthumb -o "Src/Loader_Src.o"

arm-none-eabi-gcc -o "CubeExtLoader.elf" @"objects.list"  -mcpu=cortex-m0 -T"C:\DavesStuff\CubeExtLoader\STM32F030C8TX_FLASH.ld" --specs=nosys.specs -Wl,-Map="CubeExtLoader.map" -Wl,--gc-sections -static --specs=nano.specs -mfloat-abi=soft -mthumb -Wl,--start-group -lc -lm -Wl,--end-group

c:\st\stm32cubeide_1.10.1\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: CubeExtLoader.elf section `.text' will not fit in region `RAM_D1'

c:\st\stm32cubeide_1.10.1\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: region `RAM_D1' overflowed by 4232 bytes

collect2.exe: error: ld returned 1 exit status

make[1]: *** [makefile:65: CubeExtLoader.elf] Error 1

make: *** [makefile:58: all] Error 2

"make -j4 all" terminated with exit code 2. Build might be incomplete.

[Tesla DeLorean]

Cube stuff is a bit large and clunky.

Should be able to build something that fits in 64KB

Needs space to hold blocks of data too.