Debug error: PC out of scope?

[oliverb]

What is this? I seem to have some programs that I just cannot run under ICD debug.

This one's a large controller application, but I can't run it in ICD beyond the first 20 lines.

Currently I'm using a PIC18F4320.

[zristic]

This means that program counter inside PIC went to address which does not exist. This is probably an error from our side, but we would like to see the code which caused it. Feel free to send it to zristic at mikroe com

[oliverb]

I've sent you one of the affected programs by email. This one's a short example of reading a quadrature encoder and as a sample it has the advantage of running on a standard Easypic4.

The other program fills 80% of a PIC18F4320 and runs on our own hardware so its more difficult to use as a sample. If I can't find a fragment that shows the issue I'll probably send the whole project later today.

[zristic]

Email is here, we will give it a test and fix the problem. You will be notified of the result. Thanks.

[oliverb]

I've also sent a section of the other program. It's big enough to exhibit the same behavior but I've cut out most of the subroutines so its easier to locate the start point.

[oliverb]

Turns out the second sample contains the line:

Code: Select all

  ClearBit(intcon2, RBPU)

If I rem the line out it debugs as normal.

I'm guessing this has something to do with interrupts then.
At least I think I can debug the application now.

[zristic]

Thanks for additional info. This problem is now under test and it is going to be fixed for the incoming version.

[andre]

Hello,

I have the same error message on the easyPIC4 board with 16F877 coded with mikroC . Is there a known solution please ?

André

[oliverb]

As I understand it assuming this is the same issue and not something new: the problem occurs if the Port B weak-pull-up function is enabled. The Pull-up bit is on the same control register as interrupts, which is why the issue has tended to only occur on programs with interrupts.

Its partly microchip's fault, the pull-up function shouldn't affect those pins when in ICD mode as they're meant to be controlled by a seperate ICD register. Having said that the Mikroe ICD code needs to be less sensitive to pin float.

I think the problem can be cured by turning off pull-up while you debug.

If that doesn't work there may be a hardware hack to fix it, this is completely untested and speculative but if you connected a pair of non-inverting buffers to have 1k resistors from output to input, then wired the inputs to the two ICD lines RB6 and RB7, then the pins would remain in their last state unless driven, e.g. driven low then tristate=stays low, driven high then tristate=stays high thus overruling the pull-up

[filip]

Hi,

Andre, can you please attach the project that represents this issue ?

Regards,
Filip.

[andre]

Hello,

Yes , disabling the PORTB pull-ups solves the problem.
thanks a lot for that information.
I just replaced the instruction OPTION_REG =0b00000100; with OPTION_REG =0b10000100;
and since, the debuging works fine.

Regards
André

[oliverb]

can you please attach the project that represents this issue ?

You should be able to replicate the behavior in ANY code example just by clearing the bit. It's slightly less prone to happening on 18F series relative to 16F because the port B pull-up bit is in a less commonly written register.

I'm guessing Microchip's ICD isn't affected, and I think the cure is to change the ICD code to ensure that the two lines always idle high inbetween communications, though I haven't tried putting a scope on the pins to check what's really happening.

[filip]

Hi,

If you read the Help file, mikroICD Debugger Overview topic, on the bottom of the page you will see list of common errors when trying to use mikroICD.

One of them is :

Trying to debug PIC with ICD with pull-up resistors set to ON on RB6 and RB7.

This also applies to the internal weak pull-ups.

Regards,
Filip.