>>Does STM32CubeProgrammer only provide the DFU loader for internal memory?
I think it's more of the case that is supports whatever the target side DFU Device facilitates.
The ROM based DFU implementation doesn't understand what's attached externally to the part, what pins you used, what memory IC's etc.
If you want to use DFU as a means of delivery you need to write a DFU firmware that understands the internal/external memory spaces, describes those memory interfaces to the host PC, and allows for read, erase and write operations to those memories. A ROM based loader is poorly positioned to address all possible combinations of hardware you might construct around it.
They don't download the External Loader in this context. The mechanics/model used by the boot loader is different to that used by the SWD/JTAG connectivity mode, where the ROM isn't used, and code can be moved in to RAM, along with data, and the memories programmed from there.
You could perhaps do a staged programming where you upload a new USB Device firmware into RAM, and run that, and give it the awareness of the hardware it is running on. The more considered solution is to build a loader that lives on the device permanently, and provides a means for you and your customers to update with minimal complications, and without a lot of custom host side software.
You'd need to add/expand the functionality of DFU Device examples
STM32Cube_FW_H7_V1.8.0\Middlewares\ST\STM32_USB_Device_Library\Class\DFU
STM32Cube_FW_H7_V1.8.0\Projects\STM32H743I-EVAL\Applications\USB_Device\DFU_Standalone
