cancel
Showing results for 
Search instead for 
Did you mean: 

Bug in STM32CubeIDE - Breakpoints in assembly code are one off

chriskuku
Senior II

BUG ahead!

I created an assembler project in STM32CubeIDE with my own Makefile.

When setting a breakpoint in the assembler source view and start the debug session, the breakpoint is hit but it is displayed (the arrow) one line after the actual instruction where the BP was originally set to.

See attached example. Set a breakpoint on "resetHandler" and you will see that it shows one off.

 Can anyone confirm, please? Will this Bug be fixed?

To reproduce:

  1. Right click in the Process Explorer view ->New STM32Project
  2. Choose Part Number and Board (STM32F407VG and DISCOVERY, actually irrelevant)
  3. Click on Next
  4. Give it the name "simple" and choose in Targeted Project Type: "Empty"
  5. Delete all (3) .c files in Src (confirm to delete from filesystem)
  6. Right click on the Root node of the new project
  7. Choose "Preferences" at the bottom of the dropdown menu
  8. Select the list box item C/C++ Build
  9. uncheck "Generate Makefiles automatically" in the Makefile generation section
  10. change Build Directory to ${workspace_loc:/<project>}/Src
  11. put the attached simple.zip into the workspace/simple directory and unzip it (unzip simple.zip)
  12. Delete the Startup folder and its contents.
  13. Delete the STM32*.ld files
  14. Do a Refresh on the project
  15. clean Project
  16. build project
  17. with a target connected start debugging and set a breakpoint to the first label
  18. You will notice that when the debugee stops, the arrow points to the wrong location

12 REPLIES 12

Thank you for the confirmation! I'll add the info to the ticket.

chriskuku
Senior II

Any news about the status of the ticket? It seems to me that the problem is gone. Would like to follow the ticket and what has been done to solve to problem. Could you point me to the ticket plaese.

Thanks a lot.

Christoph

Hello Christoph,

The ticket system is not accessible outside of ST. However, I dug up the ticket to see how it eventually got closed and it seems the issue was fixed when we moved to the gcc-10 toolchain. The ticket is set to be re-opened if we got more reports of the issue resurfacing but so far we haven't spotted any new reports of the problem.