MPLAB X + XC8 break at wrong line

1
votes

I've encountered a very annoying problem that has cost a lot of time for several months now.

I have a project in MPLAB X. When I use a line-breakpoint it does not break on the right line at all when debugging my project.

I am using MPLAB X v4.15

This is where I have the breakpoint, I even added the __nop() operation, but also tried it without it

This is what actually happens: The debugger breaks at the very, very wrong place. This happens every time, no matter where the actual breakpoint is.

No matter where the breakpoint is, the debugger never breaks at the right place.

  • if I put a breakpoint somewhere, it always breaks at the wrong position
  • if I then restart the debugging it breaks at the same wrong position
  • If I change the breakpoint location, the position where the program actually breaks is different, but stays the same again when i restart the program.

Some more info:

project information

Why does this happen?

Are there more people with this problem?

How do i solve this?

EDIT

Sadly, the solution suggested by K_Trenholm did not work for me. I put 3 "NOPs" in one function, but it didn't work as you suggested. See the picture below:

3 NOPs inserted in a function

but what I got:

wrong breakpoint

I would like to add that I tried various combinations of breakpoints for the NOPs. No matter what i do, the program always halts at the same PC for this case, seen in the picture above.

Thank you for your reply, it is very helpfull to even have ANY ideas on how to solve it. If you have any other ideas, I would be very grateful if you would share them!

2
picmicrochipmplab8-bitxc8

2 Answers

1
votes

Two things come to mind:

1) Compiler optimizations can cause problems with breakpoint locations/values when debugging. When debugging, turn optimizations off (if possible, it looks like in your example you're bumping up on the ceiling in terms of code size).

2) Breakpoint "Skidding". See http://microchipdeveloper.com/tls0201:skid-effect#top-of-page

One way to work around this from what I've seen is to put a couple NOP instructions after the line where you plan on placing the breakpoint. This will ensure that any "skidding" will not execute more code.

0
votes

The instruction where the break occurs will always execute completely, and anything pending in the pipeline will execute as well. For single cycle instructions, this adds a one instruction skid. For multiple cycle instructions and branches, it adds multiple cycles. So if you want to avoid to jump the debugger into a subroutine you had to include some Nop behind the breakpoint.

example:

void main (void)
{
    int x = 0;

    x++1;                  //put Breakpoint here
    Nop();
    Nop();
    Nop();                 //Debugger will stop here
    foo(x);                //so foo() is not called
}

Depending on the MCU being used the debugger will introduce a 'skid effect' upon hitting a breakpoint. The debug session will execute up to two extra instructions before halting.