Skip to main content
chriskuku
chriskuku
Senior II
May 18, 2021
Question

Bug in STM32CubeIDE - Breakpoints in assembly code are one off

  • May 18, 2021
  • 8 replies
  • 3642 views

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

This topic has been closed for replies.

8 replies

I
Imen.D
ST Technical Moderator
May 27, 2021

Hello @chriskuku​ 

 I added the topic "STM32CubeIDE" to your post in order to increase its chance to be reviewed by our experts ( @Markus GIRDLAND​ )

Imen

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Thanks
chriskuku
chriskukuAuthor
Senior II
May 27, 2021

Thanks a lot!

Markus GIRDLAND
Markus GIRDLAND
ST Employee
May 28, 2021

Hello there!

Thank you for tagging me, Imen!

I looked into the issue and from what I can see this issue only happens when a breakpoint is set at the program entry (either at the label “resetHandler�? or the first statement). Can you confirm?

My assumption is that GDB in this case will insert the breakpoint one instruction off since PC will already be at this location after reset.

If you want to debug from program entry my suggestion is to not using breakpoints but instead uncheck “Resume�? (Startup tab in the debug settings). Debugger should now connect to the state directly after reset.  

If I'm misunderstanding anything then please let me know!

chriskuku
chriskukuAuthor
Senior II
May 29, 2021

0693W00000BZaqlQAD.pngThanks Markus.

I unchecked Resume in the Debug Configuration Tab. The program stops at rstHandler (Reset vector location). There is no explicit BP set there.

But I cannot step from there on.

chriskuku
chriskukuAuthor
Senior II
May 29, 2021

I reverted to "Resume" ticked on again.

This time the first breakpoint is hit right on. Setting then another breakpoint further down (see screenshot) at "warm: nop" you can see the BP arrow being one off.

So the problem persists.

0693W00000BZar5QAD.png

chriskuku
chriskukuAuthor
Senior II
June 1, 2021

Any new findings? The issue is still there as you can see from the screen shot and it is not that it just happens at the Reset (rstHandler) entry point. I need to use breakpoints. How else should I be able to start my program and run it to a specific point of make use of all features that are possible with breakpoints (like conditions, counts, to name at least two)?

Markus GIRDLAND
Markus GIRDLAND
ST Employee
June 1, 2021

I have sent it to one of the developers to get their take on it. I'll get back to you as soon as I can.

chriskuku
chriskukuAuthor
Senior II
June 2, 2021

Yes, I should have mentioned it in my OP. Indeed, when setting the BP in the disassembly view, it is set correctly and the arrow stops right on the set BP symbol.

Markus GIRDLAND
Markus GIRDLAND
ST Employee
June 2, 2021

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

chriskuku
chriskukuAuthor
Senior II
April 13, 2022

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

Markus GIRDLAND
Markus GIRDLAND
ST Employee
April 19, 2022

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.

Terms & ConditionsAccessibility statement