Skip to main content
EThom.3
Senior II
February 11, 2026
Solved

Cannot upload bootloader via USB port (DFU), but no problem via ST-LINK

  • February 11, 2026
  • 2 replies
  • 218 views

Where to start...

I have mave made a bootloader (done this before), which is placed in the low end of the flash memory. The application is in the subsequent flash.

My board has a USB port and a DIP switch for forcing the BOOT input pin high. When I flip the DIP switch on, and power the board, I can connect STM32CubeProgrammer to the internal DFU bootloader via the USB port. I can also upload my application through the USB port. But when I try to upload my own bootloader, it fails. This is the output from STM32CubeProgrammer:

EThom3_0-1770798407409.png

However, if I connect an ST-LINK programmer to the board, I can upload the very same file with no issues. Output from STM32CubeProgrammer:

EThom3_1-1770798643779.png

Clearly, something starts to go wrong at "Not flash Memory: No erase done"

Just now, I upgraded STM32CubeProgrammer to the latest version (2.21.0), but this made no difference.

But why does it work with the ST-LINK programmer, and not through the USB port? And why can I upload the application through the USB port, but not the bootloader?

Can it have something to do with the bootloader using segments 0, 1 and 3, but not segment 2? Does the DFU bootloader dislike such things?

Best answer by EThom.3

Problem solved. It would seem that the sections in the linker script were in the wrong order. After I moved the sections I added (.idsection and .uninit_data) to other positions in the file, the linker no longer tries to add the user heap to the .elf file.

@Mike_ST thank you for the tip with the linker file.

2 replies

Mike_ST
Technical Moderator
February 11, 2026

Hello,

Not sure, but,

The elf file you're trying to upload probably contains a segment outside of the flash range, probably RAM (0x2000235C).

The ST-link debugger seems to be able to write into RAM, but the internal bootloader not, it seems to be able to write to the flash only.

I would try to check the linker file to output a binary in the flash address range or process the elf file to keep only the flash part.

EThom.3
EThom.3Author
Senior II
February 11, 2026

Hi Mike,

That's interesting. I wonder why the elf file would contain data that belongs in RAM.

Thanks a lot. Will look into it.

EThom.3
EThom.3AuthorBest answer
Senior II
February 15, 2026

Problem solved. It would seem that the sections in the linker script were in the wrong order. After I moved the sections I added (.idsection and .uninit_data) to other positions in the file, the linker no longer tries to add the user heap to the .elf file.

@Mike_ST thank you for the tip with the linker file.