Have you tried to generate post link a S19 or HEX file?
This file contains the whole memory space content and the STLink Utility should be able to flash both areas by internal MCU flash space or external chosen loader. Haven't experimented yet, just a thought on it.
Ok, I have now the Hex-File (how to get it: Get Hex-File from System Workbench). But this doesn't help me. I only have some Address-Lines in the Hex-File:
The first 4 Parts are in the Flash which begins at 0x0800(0000) and the Address 0x1000(0000) stands for RAM2 of my MCU. But the QSPI is located at 0x90000000 which I can't find in the Hex.
Btw, I can see in the Map-File, that the needed Functions are compiled in. There are only 2 Test-Functions atm:
.qspi 0x90000000 0x24 load address 0x08000188
0x90000000 . = ALIGN (0x4)
0x90000000 _qspi_start = .
.qspi 0x90000000 0x24 C:\Dat\STM32L4_Eval\libText\Debug/libText.a(text.o)
0x90000024 . = ALIGN (0x4)
0x90000024 _qspi_end = .
Writing this Answer was helpful After sending I saw the "
load address 0x08000188" above, means that the Program will try to load (initialize) the QSPI-Stuff from Flash after Starting ... The Section was not correctly defined. Now I have the
in my Hex-File, means there is Data for Address 0x9000(0000). Now I can Flash both Parts into the MCU and it works. But anyway, I can not debug and that was the real Question above.
I don't think that was the question.
The question is whether System Wastebasket can use a flash algorithm/applet to handle external memories. Perhaps via OpenOCD