When I first started trying to use the debugger I got that all the time. I don't exactly know what I changed to make it work, but I almost never see that error anymore and debugging works great.
You've selected the PICkit 2 as the debugger? Well, duh! Not sure if this is necessary but I change the Release/Debug mode thing in the top menu to Debug and re-assemble or re-compile. Then I program the chip from the Debugger menu by hitting ALT-D and then G. When that's done I debug.
Is your target circuit self powered? Or is it powered by the Junebug? Does it possibly draw too much current for the Junebug to supply? Sometimes they take more than you think, and if you've been gradually adding more stuff to the breadboard it can kind of sneak up on you. Suddenly just that one more part makes it iffy whether it works right or not. If the oscillator can't get going debug won't work.
If the target PIC programs but does not debug it's usually the target OSC isn't running. Try using the 18F1320 on the tutor to make sure the Junebug is working fine.
Do you have a pullup on the target PICs MCLR, 22K is about right. Also you can't use MCLR as an input pin when using the debugger.
I have a little test program that I use to test Unicorn crystals. Should work with the 18F2550 too.
Code:
;*** Unicorn 18F4550 crystal test
; Requires Inchworm or Junebug debugger
; Open a Watch window and "Add SFR / OSCCON"
; Make sure MPLAB 8.01 is in Debug mode
; Build All, Program, then Animate
; OSCCON = 0x48 crystal OK
; OSCCON = 0x44 crystal failed
list p=18F4550
include <p18F4550.inc>
CONFIG FOSC = HSPLL_HS, WDT = OFF, LVP = OFF
CONFIG FCMEN = ON, IESO = ON, PBADEN = OFF
CONFIG PLLDIV = 5, CPUDIV = OSC1_PLL2
org 0
loop nop
bra loop
END
2 things, the diagram I got which I used to hook in the 2550 to the Junebug didnt have a pullup on MCLR, I have put one on but it hasnt made a difference.
Thanks for the code, I was actually able to run this in debug mode and the OSCCON register reported 0x44.
I am using the internal oscillator, does this mean my 2550 has died?
I basically replaced my config directives with the ones you gave me.
Now that it debugs I started stripping out all the config settings which didnt seem to affect the PK2Error0028 setting.
So from:-
CONFIG FOSC = HSPLL_HS, WDT = OFF, LVP = OFF
CONFIG FCMEN = ON, IESO = ON, PBADEN = OFF
CONFIG PLLDIV = 5, CPUDIV = OSC1_PLL2
I got down to:-
CONFIG FOSC = HSPLL_HS,WDT = OFF, LVP = OFF, IESO = ON
and it works fine.
Sorry to be thick, but when you say "fuse" do you mean the config settings, or something else?
What does DIP1 do on the Junebug?
My project is a straight forward 18F2550 talking to an RTC (DS1307) via I2C - or it would be if I could get it working. but don't worry about that, it will be a topic for another thread.
I'm old PIC, they used to call the config bits Fuses.
Since the debug program I posted gave you 0x44 it means your crystal isn't running.
What speed crystal are you using? What caps are on it? I'm sure you've added your 0.1uf caps across the VDD, VSS pins.
FCMEN=OFF (it's on by default so no need to set it, so is IESO it too is on by default) try adding this, does the debug stop working? If so it's your crystal. Is this on a solderless breadboard?
DIP 1 is the MCLR line, it'll use the tutors reset pullup resistor on your target PIC.
I am using the internal oscillator, I have changed the FOSC config to INTIOSC_HS which should use the internal oscillator.
It is a solderless breadboard, and I have gone up and down it with my multimeter to determine shorts that may have caused the problem, so I am %90 certain it isnt the physical circuit that was the problem.
Some may be saying "Yeah, it says that in the manual". I just want to point it out as I wasn't even looking for that because my config directives are as follows;
Code:
#pragma config OSC = HS, WDT = OFF, LVP = OFF
However, for some reason or another, the PWRTE config directive was set. When I checked the configuration bits (Configure->Configuration Bits), address 300002 was 1E and should have been 1F (I only found that by trying to program some different code for the 18f2525 onto this particular chip -- which would program and enter debug -- and had a config value of 1F @ 300002). After manually disabling the PWRTE everything worked as expected, and future builds would program the correct config bits. (It didn't matter if I did a make or a build all, the config bits were still being set for the PWRTE directive.)