JLinkMOEInfo Index always -1 for code breakpoints

[mtport]

I use pylink on a Ubuntu 18 64bit and an R7FS7G27H (Renesas Synergy) core via the integrated USB debug interface of the Synergy device. Everything works fine except a problem with breakpoints. To work with breakpoints, the breakpoint is set via breakpoint_set which returns a valid handle. I then run the program until halted() returns true. Then the reason for the halt is retrieved via cpu_halt_reasons(). The instance of JLinkMOEInfo returns True for code_breakpoint(), but always contains -1 for Index. Is there a way to retrieve which breakpoint was triggered?

[hkpeprah]

So the handle and index are different. Is the breakpoint active if you call num_active_breakpoints()? If this is a software breakpoint, did you enable breakpoints by calling enable_soft_breakpoints()?

[mtport]

num_active_breakpoints returns 2 which is the correct number of breakpoints set. I also tried to use software_breakpoint_set (and also called enable_soft_breakpoints) with the same result. Some breakpoint is hit but Index always returns -1. Just for info, the installed SEGGER JLink software package is v6.32h 64bit.

[AbdelrahmanAshraf98]

I Have the same Issue , any updates ?

[hkpeprah]

Hm. Sorry. I haven't looked too much into this. Maybe as a workaround, you could read the $PC via register_read(), and use that to lookup the breakpoint via breakpoint_find(), which would give you the handle to use with breakpoint_info()? E.g.

pc = jl.register_read(index_of_pc)
handle = jl.breakpoint_find(pc)
if handle > 0:
    info = jl.breakpoint_info(handle)
    <...>

Though I'm not sure what you need the index for. Could you describe more that use case?

[AbdelrahmanAshraf98]

I want to make sure which breakpoint the CPU is halted at, I added 3 breakpoints and each time I want to check that the CPU is halted at the expected breakpoint.

[hkpeprah]

I would try the above and see if that works for your use case. You should be able to compare the handle against the handle(s) you got when you created the breakpoint.

[AbdelrahmanAshraf98]

Yes , this is exactly what I need to do , I created a breakpoint dictionary that contains all the added breakpoints handles and I expected to get the breakpoint handle from cpu_halt_reasons() to compare and assert but it didn't work .

[hkpeprah]

The cpu_halt_reasons structures don't have the handles, only the index in the breakpoint list. I would try using the address that the CPU is halted on to try and see if there is a breakpoint set there, then use that to get the handle like the above snippet I posted.

[AbdelrahmanAshraf98]

how to get the address the CPU is halted on ?

[hkpeprah]

Say you're on an ARM Cortex-M33, then your register list is this: PC or Program Counter is R15, and indicates the current address of execution. So if you pass in:

pc = jl.register_read(15)

then pc would be the address the CPU is halted on.

[AbdelrahmanAshraf98]

Thanks a lot for you help, I will try this and give you my feedback again

[AbdelrahmanAshraf98]

It Works with me, Thank you .

[hkpeprah]

Good to hear!

[AbdelrahmanAshraf98]

Hello @hkpeprah , I want to ask two more questions not related to this thread please, 1- I want to know if I can continue run after being halted at breakpoint but without removing the breakpoint ? 2- how can I read local variables ?

Thanks for your help

[hkpeprah]

1. You can use restart() and pass skip_breakpoints=True; see documentation here.
2. Reading local variables is tricky. You need to know what the compiled assembly is to see if the variables are on the stack, or in a register, and if in a register, what specific register it is. If you know the calling convention for your architecture, and your breakpoint is on a function, then it's a bit easier. Otherwise, you need to look at the generated assembly to see where the variable was placed.

[AbdelrahmanAshraf98]

restart() didn't work with me , my scenario is that I need to add 2 breakpoints then after halt I need to continue running to halt on the second breakpoint

[hkpeprah]

I would play around with the arguments to restart() if you haven't yet; I think restart(num_instructions=1, skip_breakpoints=True) should continue on by jumping over the breakpoint instruction, and continue running your firmware.

[AbdelrahmanAshraf98]

Actually I haven't used num_instructions param, I will Check This.