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

[NArnd]

Hello,

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

https://www.youtube.com/watch?v=OkUQ3iMmiYQ

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:

https://stackoverflow.com/questions/70342257/external-flash-loader-gets-failed-to-download-segment0-error-on-stm32cubeide

https://community.st.com/s/question/0D53W00001FlxnmSAB/external-flash-loader-gets-failed-to-download-segment0-error-on-stm32cubeide

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

[Wijeden RHIMI]

Hi @NArnd​ ,

Thank you for posting!

Could you please provide a complete project as well as the linker script file to help us reproduce your issue.

Best regards,

Wijeden,

[NArnd]

Hi Wijeden and thank you for quick response,

I am not at liberty to share the entire project, but please let me start by attaching two error messages (from ST-LINK GDB Server), one OK message (from OpenOCD), and the linker script files for both the Bootloader project and the Application project. I also describe what I believe you can do to reproduce the error.

As I mentioned in my previous posting, I have studied the "How to Create a Super Simple Bootloader" videos and based a slightly more elaborate design on those instructions. I started out with a work-in-progress Application project (originally generated by CubeMX) that I copied and renamed into "Bootloader".

The Bootloader project was stripped of everything not necessary for copying a firmware image from a flash storage space to the flash location of the Application. The attached linker scripts will show you the flash layout. The Bootloader project contains the bootloader flash area and the shared library area. The Application project contains the application flash area.

There are three more flash areas that are not supposed to be touched by the compiler:

• One page used for flash update status communication between application and bootloader
• A few pages for character set and local GUI texts used by the application
• The storage space typically written by the application when receiving a new FW image during regular operation. When the entire image has been received, the application does a CRC check. If successful, the application erases the flash update status page, writes two word that later tell the bootloader to copy the image to the application flash area, and resets.

At this point, much remains to be done in the Application project to support this, but both projects compile without error and the Build Analyzer window shows that the items in the shared library flash area gets placed there correctly. Also, since the OpenOCD Debug probe starts and runs without complaints, I suspect that there is a bug in a software function used by the ST-LINK GDB Server Debug probe (STM32CubeProgrammer).

The second attached error message says:

"Error: failed to download Segment[1]

Error: failed to download the File

Encountered Error when opening C:\ST\STM32CubeIDE_1.11.2\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.500.202209151145\tools\bin\STM32_Programmer_CLI.exe

Error in STM32CubeProgrammer"

I suspect this is the smoking gun you are looking for.

Please let me know if I made a mistake in the linker script files or any other improvement you would like to suggest. I will also be happy to check if bug fix attempts work and send log files and other things you need.

Best regards

Niclas

[Wijeden RHIMI]

Hello @NArnd​ ,

Your issue is not solved ?

Thanks,

Wijeden,

[NArnd]

I have not received any response.

I suggest you escalate this as an "Error in STM32CubeProgrammer".

[NArnd]

I have installed CubeIDE 1.12.0 and upgraded STLink V2 FW to V2J41S7. (I was previously running 1.11.2 with the latest STLink V2 FW at the time of 1.11.2). It's still buggy.

Luckily, it seems that whatever your guys at CubeProgrammer are messing about with doesn't seem to have broken OpenOCD.

---

Here's my updated bug report with 1.12.0:

Immediately after importing my project (bootloader + application) into 1.12.0 and switching to GDB, debugging worked without error messages, including the jump from bootloader to application. I didn't test the calls to the functions in the shared API.

The second time I tried to start GDB debugging (after uncommenting the calls to the functions in the shared API), program download failed in a fashion similar to before. See attached file 1_12_0_errors.txt.

I then switched to OpenOCD debugging, which worked, including jump from bootloader to application and calls to functions in the shared API.

Next, I switched to GDB debugging, which yet again worked, including jump from bootloader to application and calls to functions in the shared API. No code change. Presumably Open OCD has hidden healing powers. See attached file 1_12_0_not_errors.txt.

I ran a few more GDB debug sessions without code change, just to see whether the GDB error would return, but it didn't.

So, I commented out a few (not all) of the calls to the functions in the shared API, and the GDB error returned.

I started a new debug session with OpenOCD (without code change) and everything works. See attached file 1_12_0_OpenOCD.txt

I started a new debug session with GDB (without code change) and everything works.

---

So long as I don't make any code changes after OpenOCD debugging, GDB works.

When I make a code change, GDB fails.

After running OpenOCD with the same code that GDB had just failed to run, GDB starts working again until the next code change.

[Rim LANDOLSI]

Hello @NArnd​ ,

According to the last posted file, Cube programmer version is v2.13.0, but in the Error_message file for CubeIDE-1.11.2 it is v2.12.0 .

That's why the encountered problem Error appears when opening 

C:\ST\STM32CubeIDE_1.11.2\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.500.202209151145\tools\bin\STM32_Programmer_CLI.exe

Alternative to upgrading stm32CubeIDE from 1.9.0 to  1.11.2 version, you can only copy and replace the below directory contents of the STM32CubeIDE 1.11.2

C:\ST\STM32CubeIDE_1.11.2\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.500.202209151145\tools\bin

to the directory :

C:\ST\STM32CubeIDE_1.9.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.200.202202231230\tools\bin

of the STM32CubeIDE 1.9.0 .

I will be waiting for your feedback.

Thanks,

Rim

[NArnd]

In my previous post I wrote that I had just upgraded to 1.12.0.