Showing results for 
Search instead for 
Did you mean: 

Error: failed to download Segment[0] Error: failed to download the File

Associate III


I am writing a custom bootloader for STM32L4P5RET6 largely based on the "How to Create a Super Simple Bootloader" videos:

When beginning, I was using CubeIDE 1.9.0 and whatever was the latest FW for the ST-LINK V2 dongle at the time of 1.9.0's release. It compiled without error and I could see the memory regions being filled with the expected content. However, when trying to debug, I received error messages on the theme of "Error: failed to download Segment[0] Error: failed to download the File" for the bootloader, but the debug started.

After CubeIDE upgrade to 1.11.2 and also to the current FW for the ST-LINK V2 dongle, the nature of the errors changed and the debug was no longer started.

This caused me to rearrange the layout of the flash memory to this:

* Bootloader             0x0800 0000 - 0x0800 2FFF, LENGTH =  12 K, 3 pages in bank 1, pages 0 - 2

* Sharlib                0x0800 3000 - 0x0800 5FFF, LENGTH =  12 K, 3 pages in bank 1, pages 3 - 5

*  Shared api           0x0800 3000 -

*  Shared Modbus tables

*  Shared const

*  Shared func

* Image storage area     0x0800 6000 - 0x0803 FFFF, LENGTH = 232 K, 58 pages in bank 1, pages 6 - 63


* FW upgrade status page 0x0804 0000 - 0x0804 0FFF, LENGTH =   4 K, 1 page in bank 2, page  0

* Char set & GUI texts   0x8004 1000 - 0x0804 5FFF, LENGTH =  20 K, 5 pages in bank 2, pages 1 - 5

* Application            0x0804 6000 - 0x0807 FFFF, LENGTH = 232 K, 58 pages in bank 2, pages 6 - 63

(The previous layout had bootloader, "FW upgrade status page", and "Char set & GUI texts" in bank 1 and Sharlib and Application in bank 2, so I suspected that programming had failed because of the bootloader "image" had a "hole" in the middle between Bootloader and Sharlib.)

After the rearrangement, I could successfully debug once. Then CubeIDE started complaining about the same kind of problem with the application programming.

So far I had been using the ST-LINK GDB server, and on a whim I tried switching to ST-LINK OpenOCD, which doesn't complain and successfully starts and runs the debug.

It seems that CubeIDE or the integrated programmer has been flaky for quite a few releases:

This is the first time I am altering the linker scripts, so it's perfectly possible that I made some mistake. I will be happy to post the linker scripts, but I would first like to ask for a status update on what looks like a tool bug across a few releases.

BR, Niclas

ST Employee

Could you try the same alternative to upgrading stm32CubeIDE from 1.11.2 to 1.12.0.

Associate III

I'm sorry. It is not clear what you want me to do and what it's supposed to achieve. I no longer use 1.9.0 and the project has been imported and converted into 1.12.0.

Are you now instructing me to copy and replace




when I no longer can use 1.9.0 and none of 1.9.0, 1.11.2, and 1.12.0 seem to have a fully functional CubeProgrammer?

This posting claims you need to go back to 1.7.0, because 1.8.0 was where the bugs appeared:

This posting claims you might have to go back to 1.6.0:

I referred to both of these postings in my original message. Their recommendations are opposite to yours.