Odd PICkit2 Debugging issue

[jrandombob]

Hi All,

         New to the forum but I've been playing with electronics for the past 20 odd years...

Thought this might be a good place to ask as there seems to be a good deal of knowledge around.

It's been quite a number of years since I've touched a PIC but a recent repair has dragged me back into the world of Microchip. I'm working on re-writing firmware for a simple controller, but I've run into an odd issue when I attempt to get debugging to work MPLAB X.

My target is a PIC16F627A, and I'm using the AC162053 debug header driven by a PICkit2 for this part of the development (I've had it lying around for a LOOONG time but this is the first time I've actually used it).

My code is setting the config bits appropriately (WDT/BOR/PWRT/LVP disabled, MCLR enabled), and using the internal oscillator, other than that it's a rock simple LED flashing "Hello World" type of thing.

Here's the output from the PICkit2 window;

Code: [Select]

Found PICkit 2 - Operating System Version 2.32.0
PICkit 2 Settings: Using target power always.
Target power detected ( 4.99V)
2015-12-21 14:57:50
PIC16F627A found (rev = 0x4)
Erasing Target
Programming Program Memory (0x0 - 0x2)
Programming Program Memory (0x2cf - 0x2ff)
Verifying Program Memory (0x0 - 0x2)
Verifying Program Memory (0x2cf - 0x2ff)
Programming Debug Executive (0xf00 - 0x3ff)
Verifying Debug Executive (f00 - 3ff)
Programming Debug Vector
Verifying Debug Vector
Programming Configuration Memory
Verifying Configuration Memory
PK2Error0028:  Unable to enter debug mode
NOTE: This device requires an ICD Header for debug.  See "Header Specification" DS51292.
Running Target
PK2Error0028:  Unable to enter debug mode

Originally it was failing to detect my Target Vdd properly (it showed 3.3V where my target is 5V), but that seems to have resolved itself :/ At least I think it was still reporting it incorrectly after I upgraded the PICkit2 firmware... (gotta love it when stuff spontaneously starts behaving)

I've done some searching around on this issue but everywhere I've found the issue being discussed it's been due to the person not using the required debug header, and as such the answers don't really apply to me, I gather the message gets displayed whenever you attempt to debug a device which requires the header whether you have the header or not.

If anybody could offer some insight that would be excellent.

Thanks

- JRB

[Ian.M]

Can you confirm that you have removed the PIC from the target board, and replaced it with the AC162053, with the PICkit 2 connected via an adapter to the 6P6C modular jack socket on the header?  The header should have a 28 pin PIC16F648A-ICD fitted to it.

It may be worth trying MPLAB 8.92 which is likelly to be more stable debugging such an old PIC with a PICkit 2.   I have MPLAB 8 set NOT to autoconnect to the PICkit 2 and NOT to reprogram the chip on a successful build, as I have found that when debugging 8 bit PICs,  after programming the PIC or header with the debug build it can take a couple of attempts to enter debug mode successfully, and that way, I only have to reset the target from the debugger toolbar (and sometimes reconnect to the PICkit 2 from the same toolbar) for the debugger to start sucessfully.  Also, under MPLAB 8, a crashed debugger can often be unjammed by selecting MPLAB SIM then reselecting the debugger, connecting and resetting the target, but on MPLAB X debugger crashes usually require exiting and restarting the IDE, and sometimes need Windows rebooted as well.

MPLAB 8 coexists happily with MPLAB X as long as you don't let them fight over a programmer/debugger or try to build the same project at the same time from both.

[jrandombob]

I don't actually have the PIC16F627A yet

The plan is to develop and test the code using the debug header then once I'm happy with it swap out for the "real thing". So in answer to your question, yes, PICKit2->AC164110->AC162053(with PIC16F648A-ICD onboard)->target board.

I'm developing the code in C (mainly because I'm lazy), using XC8, will MPLAB 8 work with the XC8 compiler? I never had much luck getting the hitech(?) C-compiler they used to supply to play nicely with MPLAB "back in the day"

[Ian.M]

Have you got a 0.1uF decoupling cap across the Vdd and Vss pins as close to the header as possible?

XC8 works fine with MPLAB 8.92.   There *may* be a problem with the latest version failing to register its toolsuite properly, because the DLLs used have been depreciated. It isn't a problem if you have V1.30 - v1.33 installed OK and simply add an installation of v1.35.

[jrandombob]

There was, but being that its a breadboard build at the moment, one is never sure how much to trust it, so I bodged one onto the back of the RJ12 on the debug header board (I note there's an unpopulated 0603 footprint there...), no change.

OK, I'll have a go at it from MPLAB 8.92.

[jrandombob]

Yeah, I'm using 1.33 so no dramas there, was able to create a project targeting XC8 and build the code without issue.

Unfortunately I'm still getting the same result. When I attempt to run the debugger I get a pop up "PK2Error0028: Unable to enter debug mode", tried to Run it half-a-dozen times.

Is there any way to get more verbose info out of MPLAB around this?

[Ian.M]

I assume you've started off with a very basic 'hello world' code that simply blinks a LED or similar.  If you post your code, I'll see if it contains anything that usually causes problems with debugging.

[jrandombob]

Sure.

Code: [Select]

#define _XTAL_FREQ 4000000

#pragma config FOSC = INTOSCIO  // Oscillator Selection bits (INTOSC oscillator: I/O function on RA6/OSC2/CLKOUT pin, I/O function on RA7/OSC1/CLKIN)
#pragma config WDTE = OFF       // Watchdog Timer Enable bit (WDT disabled)
#pragma config PWRTE = OFF      // Power-up Timer Enable bit (PWRT disabled)
#pragma config MCLRE = ON       // RA5/MCLR/VPP Pin Function Select bit (RA5/MCLR/VPP pin function is MCLR)
#pragma config BOREN = ON       // Brown-out Detect Enable bit (BOD enabled)
#pragma config LVP = OFF         // Low-Voltage Programming Enable bit (RB4/PGM pin has PGM function, low-voltage programming enabled)
#pragma config CPD = OFF        // Data EE Memory Code Protection bit (Data memory code protection off)
#pragma config CP = OFF         // Flash Program Memory Code Protection bit (Code protection off)

#include <xc.h>

void initPorts(void)
{
    PCON = PCON | 0b00001000; // Make sure INTRC is running at 4MHz
    TRISB = 0b00000000;
    PORTB = 0;
}

void main(void) {
    initPorts();
   
    while (1){
        __delay_ms(15000);
        PORTB = 0xff;
        __delay_ms(2000);
        PORTB = 0;
    }
}



[Ian.M]

Try with BOREN off.  Also try with FOSC = INTOSCCLK and check for a 1MHz squarewave on the OSC2 pin to confirm the oscillator is running.   Otherwise it looks fine.

Check the project's build options, linker tab and make sure the debugger list box in the right hand coluum is set to 'Auto (PICkit 2)' or 'PICkit 2'  If its set to 'None' the linker doesn't add the NOP at address zero required for debug executive initialisation, and if its set for the wrog debugger, the C runtime may stomp on the debugger's reserved memory.

[jrandombob]

Derp, for some reason I was under the impression I'd turned BOREN off.

Flipping BOREN off hasn't resolved the issue, tried "Auto (PICkit2)" and "PICkit2" in linker options, no change.

I'll change oscillator modes and break out the o'scope tomorrow.

Thanks for your assistance so far.

[picandmix]

Am sure Ian will keep you on the right track, but as you said you have not yet got a 16F627 chip then I would say avoid them.

First they are not the best choice of chip in that range, and importantly other better chips like the 16F88 which also have an inbuilt debugger so do not need the addition of another debugger header /pic chip  which can only complicate things.

How do you know which chips have an inbuilt debugger, if you use MPlab DE V8.92 , its Configure panel will show you.

[jrandombob]

Thanks for the suggestion picandmix but it's not a viable solution in this case.

This is not a scratch build, I'm writing new firmware for a commercial controller whose PIC16F627 has developed Alzheimers (I refuse to pay $300 for a replacement unit, and there's no way the manufacturer will give me just the uC), in any case the controller uses all available I/O resources so tying up the ICSP pins for debugging is not an option.

[Ian.M]

Also, there is the issue that the PIC16F88 has the UART pins in different places to the PIC16F628A.   However it would certainly simplify things if you had a natively debug capable chip on a solderless breadboard that could be used to confirm your toolchain's debug capability, especially the PICkit 2.

Incidentally, Is this a genuine Microchip PICkit 2, and what colour button does it have?

Is the debugger to target cable the original short one that came with the AC164110?

I just had another thought - try *JUST* the header, with a 10K pullup on the /MCLR pin of its target connector, powered by the PICkit 2 @ 5V.

[jrandombob]

However it would certainly simplify things if you had a natively debug capable chip on a solderless breadboard that could be used to confirm your toolchain's debug capability, especially the PICkit 2.

I've a case of older PICs kicking around somewhere, some of them may be debug capable, I *think* there's some 18F4550's or something in there which ISTR should be debug capable, I'll see if I can turn them up tomorrow.

Incidentally, what colour button does the PICkit 2 have?

Red button, the build date on the board is 2007 so shouldn't have the issues which the earlier ones had around shorting Vdd to ground or whatever it was, might be worth poking a multimeter at D4 just in case.

Is the debugger to target cable the original short one that came with the AC164110?

Yeah, original ~100mm cable.

I just had another thought - try *JUST* the header, with a 10K pullup on the /MCLR pin of its target connector, powered by the PICkit 2 @ 5V.

I'll add that to my list for tomorrow

EDIT: just had a look in my parts drawers (the case o' PICs is out in the garage), I've got some 18LF452's which are debug capable but I can only find the F variant in MPLAB 8.92, not sure if I can get away with configuring for 18F452 but using 18LF452, device ID won't match but I imagine the code ought to run still?

[Ian.M]

The issue was: Early (black button) PICkit 2 programmer/debuggers didn't have pulldowns on PGC and PGD that were needed for debug mode.  You can assume that all genuine red button units have them.

I was *HOPING* for a debug capable PIC16 part as that would be a closer test of the toolchain.   

The older chips didn't have separate F and LF masks, it was just a matter of of process variation and which voltage 'bin' the wafers tested into, so using them and debugging them as PIC18F452 should be fine.  Decouple both pairs of power pins (Vdd,Vss) as close to the chip as possible with 0.1uF and connect all of them! They will need a clock signal - I suggest RC mode with a 22pF cap to Vss on OSC1 and a 3K3 pullup which should give you about 3.2MHz with a Fosc/4 output of 0.8MHz on OSC2.   Don't go lower for R or C, but there would be no problem doubling either if you don't have exactly the right parts handy.  The only other thing that's essential is a 10K /MCLR pullup - it will debug without it but wont run reliably standalone.

[jrandombob]

OK, I'll dig up my case o' PICs and see if I've a debug capable PIC16 in there, if not I'll run the test on the PIC18 part.

[Ian.M]

I posted a spreadheet for MPLAB 8.92 part support over at Ric's PicForum that includes the debug header part numbers. http://picforum.ric323.com/viewtopic.php?f=27&t=92

You can filter by device family and whichever debugger you have and no debug header (or optional) then match the resulting list against your PIC stock-in-hand.

[jrandombob]

So Murphy strikes of course, went looking for my case o' PICs, found my stash of about 2 dozen PIC18 devices, but can't for the life of me find my PIC16's (which is rather irritating since I KNOW there are some 16F877's there and those are debug capable)...

The good(?) news is that I was able to debug code on an 18F2431.

I also tried just the header alone with a pull up on MCLR, no difference there, nothing on OSCOUT either.

So this would seem to suggest that my PICkit2 is fine but the debug header is dead :/

[Ian.M]

Register with Microchip and put in a support ticket.  The worst that can happen is they tell you to 'pound sand' but they do have a tendency to go far beyond their warranty obligations and help with problems long after purchase.  You may also want to register with their forum as a number of their techs hang out there and are generally helpful to anyone who has at least half a clue, + there are a significant number of very experienced PIC users there.

Another option for a one-off project would be to build an adapter that let you hook up a debug capable 28 pin PIC (or a 20 pin one if /MCLR on the target isn't used as an input) to an 18 pin socket.  Break out the ICSP/ICD pins separately.  The QFN-28 package is 6mm square so can be superglued dead-bug on top of a standard 0.3" turned pin DIP socket with just enough room to solder Kynar or magnet wire into each pin of the socket.  Be careful of the pin mapping if any hardware peripherals are used and reinforce with hotglue!

[jrandombob]

Thanks Ian, I'll try give it a go.

[Howardlong]

Sorry, I'm a bit late to the party on this one.

I have the AC162053 header in stock and ran up the code in MPLAB 8.92 using PIC16F827A as the target. (I have PIC16F628 chips in stock but not the '627 nor the A versions I'm afraid, the non-A versions have no debug facilities). This works, and whether there's a 10k pullup on MCLR or not doesn't seem to make any difference, but as a matter of course I put one on anyway.

Edit: I just found some '648As (same as '627A but with more memory), so if necessary I can breadboard one up as necessary if it comes to that.

Code: [Select]

#define _XTAL_FREQ 4000000

//#pragma config FOSC = INTOSCIO  // Oscillator Selection bits (INTOSC oscillator: I/O function on RA6/OSC2/CLKOUT pin, I/O function on RA7/OSC1/CLKIN)
#pragma config FOSC = INTOSCCLK  // Oscillator Selection bits (INTOSC oscillator: I/O function on RA6/OSC2/CLKOUT pin, I/O function on RA7/OSC1/CLKIN)
#pragma config WDTE = OFF       // Watchdog Timer Enable bit (WDT disabled)
#pragma config PWRTE = OFF      // Power-up Timer Enable bit (PWRT disabled)
#pragma config MCLRE = ON       // RA5/MCLR/VPP Pin Function Select bit (RA5/MCLR/VPP pin function is MCLR)
//#pragma config BOREN = ON       // Brown-out Detect Enable bit (BOD enabled)
#pragma config BOREN = OFF       // Brown-out Detect Enable bit (BOD enabled)
#pragma config LVP = OFF         // Low-Voltage Programming Enable bit (RB4/PGM pin has PGM function, low-voltage programming enabled)
#pragma config CPD = OFF        // Data EE Memory Code Protection bit (Data memory code protection off)
#pragma config CP = OFF         // Flash Program Memory Code Protection bit (Code protection off)

#include <xc.h>

void initPorts(void)
{
    PCON = PCON | 0b00001000; // Make sure INTRC is running at 4MHz
    TRISB = 0b00000000;
    PORTB = 0;
}

void main(void) {
    initPorts();
   
    while (1){
        __delay_ms(15000);
        PORTB = 0xff;
        __delay_ms(2000);
        PORTB = 0;
    }
}

Pickit2 output:

Code: [Select]

Found PICkit 2 - Operating System Version 2.32.0
Target power not detected - Powering from PICkit 2 ( 5.00V)
PIC16F627A found (Rev 0x4)
PICkit 2 Ready

Resetting
Programming Target (03/01/2016  09:40:00)
PIC16F627A found (Rev 0x4)
Erasing Target
Programming Program Memory (0x0 - 0x2)
Programming Program Memory (0x2D4 - 0x2FF)
Verifying Program Memory (0x0 - 0x2)
Verifying Program Memory (0x2D4 - 0x2FF)
Programming Debug Executive (0x-F00 - 0x3FF)
Verifying Debug Executive (0xF00 - 0x3FF)
Programming Debug Vector
Verifying Debug Vector
Programming Configuration Memory
Verifying Configuration Memory
Debug mode entered, DE Version = 1.1.0
PICkit 2 Ready


[jrandombob]

Thanks Howardlong.

I'd already tried with BOREN=OFF. That the code worked for you on your header would seem to confirm that the issue is my header, I'm going to raise a ticket with Microchip today and see what they say.

[jrandombob]

Sorry to Lazarus this thread but I figure it'd probably be nice if this was actually online somewhere.

The issue is resolved, the AC164053 debug header *WILL NOT* work without target power, i.e. you can't power it from the PICkit, that ended up being the issue here, of course I didn't even think to try that because one would assume that if you can power the target device from PICkit you ought to be able to do the same with the debug header.