Well, the way I usually solve it is to add a line exactly where I want it to
break, and remake the project.  Then I can use run-to-here and it all works
normally.

In Hi-Tech C, define

#define b #asm("nop")

Then add

b;

to add a breakpoint wherever you want.

I dont think theres a switch to correct this problem with MPLab.

- Shane.


> -----Original Message-----
> From: robert a. moeser [SMTP:ram@tiac.net]
> Sent: Tuesday, September 21, 1999 3:14 PM
> To:   PICLIST@mitvma.mit.edu
> Subject:      MPLAB question #497
>
> hi!
>
> this is MPLAB question #497 - i spared you all questions 0-496, but
> this one is buggin' me.
>
> please think back over all the debuggers and all the simulators you've
> used and tell me how many did things the way MPLAB does with respect to
> breakpoints.
>
> MPLAB breaks *after* the instruction at an address has executed. this
> lands you up, at times, miles away from the breakpoint (GOTO, CALL).
>
> this is, i swear, not the case in any other debugger/simulator i've
> ever used and i am finding it mighty hard to get used to and a bit of a
> challenge, so i guess i'm looking for you to say you agree or that it's
> OK, i'll figure it out one day.
>
> i remember implementing breakpoints myself (never mind how long ago) and
> it seems that it would actually be harder to do it MPLAB's way.
>
> it seems more logical, not just that i am used to it - after all, if
> you want the MPLAB behaviour from another debugger, all you gotta do is
> "step" once after a break-before-execute-type break point, while with
> MPLAB, there is no work-around except in some cases adding strategic
> NOPs to one's code. and as i say, that doesn't handle all cases.
>
> have i overlooked a switch or option that would make the breakpoint
> take effect *before* the instruction at the address?
>
> orperhaps i have overlooked an "unstep" hotkey in MPLAB?
>
> i'd supply examples of the really frustrating cases, but i figure
> either you know what i'm talking about or you don't have much use for
> breakpoints. :-)
>
> i guess i should not complain, the price of MPLAB is certainly right (!),
> i just would like to read  a coherent defense of this design decision
> and then i might shut up and get over it and get used to it and make do
> as best i can.
>
> thanks.
>
> -- rob