2023-02-01 01:48 AM
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:
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
2023-03-13 03:43 AM
Could you try the same alternative to upgrading stm32CubeIDE from 1.11.2 to 1.12.0.
2023-03-13 04:38 AM
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
C:\ST\STM32CubeIDE_1.12.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.600.202301161003\tools\bin\
to
C:\ST\STM32CubeIDE_1.9.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.200.202202231230\tools\bin
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.