Bug in STM32CubeIDE - Breakpoints in assembly code are one off

[chriskuku]

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

[Imen.D]

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

[chriskuku]

Thanks a lot!

[Markus GIRDLAND]

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]

Thanks 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]

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.

[chriskuku]

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]

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.

[Markus GIRDLAND]

Hello again,

I will relay what the developer told me here:

"I tried the �?simple.s�? provided in your attachment. I needed to remap the application code to 0x800000 in the linker file in order to get it to flash properly on a F4 device. 

I can confirm the issue. A breakpoint on row 36 will in fact install the breakpoint one statement off. Not sure why GDB does this mapping. I will file a bug-report on this and try to investigate deeper."

As a last note in order to get as much information as possible in the bug-report, can you try to use instruction stepping and address breakpoints via the “Disassembly�?-view instead and see if this behavior changes for you?

[chriskuku]

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.