pic18f13k22 + pickit2 + mplab xc8 = clock problem?

[bluevd]

Hello folks,

during the last 2 days I've been bashing my head with an unusual problem: up until now I've played along with a few pic18f13k22's using the old mplab 8.92 & c18 3.47 and programming them with the stand-alone pickit2 programmer (which according to microchip officially supports pic18f13k22). Once you setup the proper config flags and the OSCCON bits, you can get the expected behavior when it comes to delay routines (for example, using Delay<xx>KTCYx() works as expected in c18; in mikropascal delay_ms works also).
But using the latest version of mplab x and xc8, everything goes haywire (using the same Delay<xx>KTCYx() as in c18 produces far faster blink rates). I've double & triple checked my code and all is ok. Also I used MikroPascal Pro to eliminate it out. No matter what I do, if I try to do the simplest led blinking pic setup, it never runs at the expected frequency. In the programmer, the config flags all show up ok, for all 3 compilers. It's just that flashing the xc8 hex with pickit2 seems to screw up something internally. Since I'm on a low budget at the time (unemployed) and I don't have a scope, I'm interested if there's someone that has a pickit2 & pic18f13k22 that can give it a few shots to see if indeed the issue is reproducible. As a mention, I did compile the code with xc8 in both "normal" mode and "trial" mode with all the fancy bells and whistles.

[dannyf]

The use of a compiler shouldn't make a difference here.

generally, I specify all fuse settings and my own initialization in the code to minimize such issues.

I would also read compiler manual to make sure that all conditions for those delay routines are satisfied correctly.

[David_AVD]

Is the timing correct if you run the simulator, use a break point and check the watch window?

[bluevd]

The use of a compiler shouldn't make a difference here.

I thought the same thing, but both MikroPascal Pro and the old c18 and mplab are ok.

generally, I specify all fuse settings and my own initialization in the code to minimize such issues.

Did that to no avail. Used the same values in all 3 IDE's

I would also read compiler manual to make sure that all conditions for those delay routines are satisfied correctly.

Started to read through the docs. However, the Delay<xx>KTCYx() should work out of the box. Just call them x times at the running frequency to get the proper delay. It doesn't work. I'm thinking of using the CLKOUT and trying to read that with another pic to see the clock freq (this would be the only way I can check it without a scope) though I'm not sure if this will work.

Is the timing correct if you run the simulator, use a break point and check the watch window?

Doing this right now.

[dannyf]

It doesn't work.

Then post a minimalist version of your code that exhibits the problem. So others can try as well.

[David_AVD]

What is the expected frequency (LED flash rate) ?  What was the actual?  Are they related in some suspicious way (such as 4x indicating PLL config error) ?

[thejamesclan]

Hi, I use the pickit2 logic analyzer to check basic timing, It can give good results at slow speeds.