Unable to continue after BKPT instruction

[Arnodejagerrr]

Hi!

We have an LPC54618, and an MCU-link debugger. We sometimes have a need for a high amount of breakpoints, in order to find bugs. To do this, we add __BKPT() instructions to our program. When such an instruction is hit, but the state of the program at that moment in time isn't suspicious, we would like to continue the program, just like you would with regular breakpoints.

However, it seems that this isn't possible. What we observe, is that pressing 'continue' makes the program hit the breakpoint again, without actually continueing. And doing single step instructions makes the program hang (pausing the application manually shows that the PC didn't move).

Are you aware of this issue, and is this an issue of our new MCU-Link debuggers, of the target processor, or of the gdb server?

Kind regards,

Arno

[ErichStyger]

This is actually not an issue, but by design with the ARM architecture: if you hit a breakpoint instruction on the target with the debug block active, it causes the target to stop (otherwise it will hardfault) and raises a SIGTRAP to the gdb client.

If you want to skip the BKPT instruction in such a case, you could add a script to gdb to do whatever you want.

I hope this helps,

Erich

[ErichStyger]

Hi @Arnodejagerrr ,

have a look at https://mcuoneclipse.com/2023/05/31/catchpoints-unlimited-number-of-flash-breakpoints-with-gdb/

I use the SIGTRAP catching to skip bkpt instructions.

I hope this helps,

Erich

[Arnodejagerrr]

Hi @ErichStyger ,

Thank you for that post! I now understand the (technical) reason why it works the way that it does, and I learned some new things about GDB.

However, from a user experience point of view it doesn't work very intuitively. As a software engineer I expect to be able to continue from breakpoints, and not having to add custom scripts and knowing about these technical details. So I'm still convinced that MCUXpresso (or actually GDB, since it is more closely tied to the problem and the solution?) should have better support for this, e.g. having your set $pc=$pc+2 script by default. I hope that you can share this opinion.

Arno

[ErichStyger · Accepted solution]

Hi @Arnodejagerrr ,

As a software engineer for embedded hardware, you would have to respect the way the hardware works. In this case the GDB is doing exactly what it is supposed to do: to catch the SIGTRAP exception and to show the PC and location where the hardware has caused the exception.

Having the GDB doing some side effects (like PC+=2) might sound like a good thing from one point of view, but is not in line what GDB is designed to. Doing some side effects like you suggest automatically will break existing scripts and use cases, and could be potentially dangerous too.

So the best way if you really want the target to run on a BKPT instruction is to use the script I have described.

I hope this helps,

Erich

[Arnodejagerrr]

@ErichStyger I understand and respect your point of view. I still believe that many software engineers won't be aware of this workaround. But then again, many software engineers also won't be aware of the BKPT instruction in the first place.

I explained the mechanism to my colleagues. We've learned something new, and will implement your solution.

[Alice_Yang]

Hello @Arnodejagerrr 

Could you please send a simple project that I can reproduce the issue on my side, and also the detail steps, I will help to check the issue, thanks.

BR

Alice