JuneBug + PK2Error0028

[UTMonkey]

Hi All,

I have been debugging my 18F2550 quite happily over the past few days and tonight it just won't debug.

I get the PK2Error0028 message "Cannot enter debug mode"

It appear to program\erase OK.

Any ideas?

Thanks in advance.

Mark

 

[futz]

I have been debugging my 18F2550 quite happily over the past few days and tonight it just won't debug.

I get the PK2Error0028 message "Cannot enter debug mode"

It appear to program\erase OK.

Any ideas?

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.

 

[UTMonkey]

Thanks for the tips, but I am afraid it hasnt made any difference.

Is it likely that I inadvertently set something on the 2550 that has stopped it from being debugged which I cannot reset?

Mark

 

[blueroomelectronics]

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.

;*** 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

 

[UTMonkey]

Hi Bill,

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?

Thanks for your help.

Mark

p.s. my Junebug works fine in tutor mode

 

[blueroomelectronics]

No it's simply a crystal check, if you're not using a 8MHz thru 20MHz crystal it will fail and that's normal.

Here's a tip, put DIP switch on the Junebug 1=on all others off. See if your 18F2550 debugs.

PS If you want to use USB you must use a crystal with the 18F2550.

Post your code at least the config fuse settings...

 

[UTMonkey]

Hmmmm, today it debugs fine.

I have made a few changes though.....

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.

Many thanks for your help.

Mark

 

[blueroomelectronics]

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.

 

[UTMonkey]

Ahhh I see,

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.

Thanks for the tips.

Mark

p.s. any good at I2c?

 

[blueroomelectronics]

any good at I2c?

I used to be, I wrote a multimaster system for the 16F877 years ago but have long misplaced the code.

 

[UTMonkey]

only joking, i'll post a new thread.

 

[0xFF]

Had the infamous "PK2Error0028" on my Junebug yesterday -- here's what I found.

I guess the best statement is this -->

Config words that enable the WDT (watchdog), PWRTE (power up timer) or disable /MCLR are INCOMPATIBLE with debugging."

(C&P from a post in the microchip forums)

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;

#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.)

Hope this saves someone a heap of time, someday!