cancel
Showing results for 
Search instead for 
Did you mean: 

STM32Cube IDE v1.8 not be able to download to Discovery L5 board anymore

mkrug
Associate III

I upgraded to v1.8 and realized that my programs cannot be downloaded anymore to my discovery STM32L5 board. The error message says:

Erasing memory corresponding to segment 0:

Erasing internal memory sectors [0 9]

Download in Progress:

Error: Fail to write buffer in flash

Error: failed to erase memory

Upto that message all other status messages looks fine. I assume it is related to ST-LINK GDB server. Version 6.0.0 because in STM32Cube IDE this was version 5.x.x.

The STM32Programmer is still able to download to the board. If I connect the STM32Programmer right after an unsuccessful download of STM32CubeIDE I can see that parts of the memory get deleted but not programmed correct afterwards (see screenshot attached). The first 8 Bytes are correct. After that only erased memory cells are shown.

Would be great if this can be fixed soon.

Best Regards

Markus

14 REPLIES 14

I haven't been able to reproduce.

My initial thought is that it could be firewall and/or antivirus related.

Could you try to connect to remote GDB server? Perhaps first through the debug configuration (debugger tab) and if that doesn't work through a command interface?

You can see the command line used by clicking the "Show Command Line" button in the debugger tab.

truhann
Associate

Same problem on our side. 1.7.0 works, 1.8.0 not.

mattias norlander
ST Employee

Could you try to see if this is working in CubeIDE 1.9.0?

In 1.9.0 (released yesterday) we have:

  • Better auto-negotiation of SWD frequency. On some boards the communication is not stable and the user had to manually select a lower freq. CubeProg stand-alone could already managed auto-negotiation of the SWD freq. But now it is also supported in ST-LINK GDB server. Could explain why it worked in CubeProg but not GDB server... So either try 1.9.0 or manually lower the swd freq in 1.8.0 in debug config.
  • There is also a bit more verbose logging in the GDB server which could give us more hints
  • The launch and terminate sequence of debug has been improved. First dirty-fix came already in 1.8.0. In 1.9.0 we have up-streamed fixes to the CDT platform to get rid of an identified race condition which left ST-LINK in a bad state.

It would also be interesting to know if the CubeProg_CLI version bundled inside the CubeIDE 1.8.0 installation is able to flash program the L5. It is found here:

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

  • You can replace this bin folder with the same folder from the 1.7.0 installation as well, to try to see if that fixes the issue or not. That would help us rule out CubeProg or not...
    • Of course remember to make copy of the bin folder.

Please share your findings!

Nikita91
Lead II

Uninstall CubeIDE 1.6.1

Reboot

Install CubeIDE 1.9

Start and build a new project for NUCLEO-F446RE

Start a debug session: OK

Start again a debug session: ST-LINK_gdbserver.exe not found!!!!!!!!!!!!!

ST-LINK_gdbserver.exe disappeared from the folder .../tools/bin

Then:

Uninstall CubeIDE 1.9

Install again

Save the file ST-LINK_gdbserver.exe

Debug session OK

Debug session fail: ST-LINK_gdbserver.exe not found

Then try to restore ST-LINK_gdbserver.exe =>

Invalid permission. Even as administrator I cannot restore it in the folder.

I give up for today...

The 1.9 problem was related to Avast antivirus who quarantined silently some files...

With quarantine exceptions, Cube 1.9 works for me.