2
\$\begingroup\$

I used to do quite a bit of PIC programming in the mid 2000's, but haven't done anything in more than a decade.

So I bought a PicKit-4 and several 16F88 chips for a project. I managed to get MPLAB and the XC8 compiler up and running, and I've been able to download the finished code to the chip. I've verified the code is actually on the chip by downloading the memory and comparing the HEX file.

I found this 16F88-specific tutorial which is about as simple as it gets: https://theembeddedlab.com/tutorials/pic-microcontroller-led_blink/

My code is verbatim to the code presented there. I have 5V connected to VDD, VSS to ground, and have tried using pins from both ports to no avail. It just does nothing.

I have 3 16F88 chips and I've tried 2 of them so far...don't want to try the 3rd until I'm sure I'm not somehow screwing it up. But both chips still accept programming and verify correctly.

Any ideas where I might be going wrong?

\$\endgroup\$
7
  • 1
    \$\begingroup\$ Can you post the full code, as is in your IDE? The tutorial is somewhat fragmented and hard to follow. \$\endgroup\$
    – anrieff
    Nov 2, 2019 at 15:28
  • 2
    \$\begingroup\$ you may also want to pull up !MCLR. Older debuggers were doing it for us, newer ones tend to tri-state it. \$\endgroup\$ Nov 2, 2019 at 15:40
  • 1
    \$\begingroup\$ Can you run the debugger? \$\endgroup\$
    – sstobbe
    Nov 2, 2019 at 15:53
  • 1
    \$\begingroup\$ There was a well-known bug on the early PIC 16F8xx chips which caused the ports to latch on boot-up and remain latched regardless of future attempts to clear them. This happened arbitrarily. The cure was to always clear the ports, eg CLRF porta and CLRF portb, as the very first lines of code. \$\endgroup\$
    – Chu
    Nov 2, 2019 at 16:12
  • 1
    \$\begingroup\$ You have all those pragmas as well? Bypass cap across the supply? \$\endgroup\$ Nov 3, 2019 at 6:02

6 Answers 6

4
\$\begingroup\$

If you follow the instructions in the PICkit 4 Getting Started Guide you will find this picture that shows the need to provide a pullup resistor on the MCLR pin of the MCU on your PC board or breadboard.

enter image description here

Here is where you can find the document: https://www.microchip.com/developmenttools/ProductDetails/PG164140

Note I posted this answer primarily to provide evidence of the documentation.

\$\endgroup\$
1
\$\begingroup\$

The MCLR shouldn't be left floating. If it is the PIC may be in reset. MCLR should be pulled to Vcc to keep the pic out of reset. Maybe the programmer, if attached will hold MCLR high. If it doesn't, put a diode between Vcc and MCLR (cathode to MCLR). The diode will pull MCLR up to near Vcc but becomes reverse biased when the programmer applies the programming voltage.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ If you place a diode between VCC and MCLR such that the cathode is at MCLR the programming pod will be unable to pull MCLR all the way to GND. The diode would clamp the MCLR pin to one diode drop below VCC and depending upon the supply capabilities a lot of current could flow through the diode and into the programmer pod. If the pod pins have limited protection this could fry the pods MCLR driver component. Suggest using a resistor instead of a diode. \$\endgroup\$ Nov 2, 2019 at 16:45
  • \$\begingroup\$ Point taken, the diode needs a 10k resistor in series with it or it's usual to use just a resistor. If just a resistor is used it should be high enough in value to avoid back driving the +5V supply or loading the programmer too much. 4k7 to 10k is usual. \$\endgroup\$
    – user173271
    Nov 2, 2019 at 17:50
  • \$\begingroup\$ Thanks for changing the resistor size to be much larger than 1K. If using too small of resistor without the diode, even if the VCC supply and other circuits can swallow the back feed current the VPP source is asked to source way more current that it should have to. \$\endgroup\$ Nov 2, 2019 at 18:48
1
\$\begingroup\$

Just for the heck of it, I wired up a PIC on a breadboard to an ICD4 and compiled that code. I had to change a few lines and remove 3 #pragma statements because I didn't have a 16F88 in DIP (but did have a 16F819, which is fairly close).

Worked fine. Here's the exact code:

#pragma config FOSC = INTOSCIO  // Oscillator Selection bits (INTRC oscillator; port I/O function on both RA6/OSC2/CLKO pin and RA7/OSC1/CLKI pin)
#pragma config WDTE = OFF       // Watchdog Timer Enable bit (WDT disabled)
#pragma config PWRTE = OFF      // Power-up Timer Enable bit (PWRT disabled)
#pragma config MCLRE = OFF      // RA5/MCLR/VPP Pin Function Select bit (RA5/MCLR/VPP pin function is digital I/O, MCLR internally tied to VDD)
#pragma config BOREN = OFF      // Brown-out Reset Enable bit (BOR disabled)
#pragma config LVP = ON         // Low-Voltage Programming Enable bit (RB3/PGM pin has PGM function, Low-Voltage Programming enabled)
#pragma config CPD = OFF        // Data EE Memory Code Protection bit (Code protection off)
#pragma config WRT = OFF        // Flash Program Memory Write Enable bits (Write protection off)
//#pragma config CCPMX = RB0      // CCP1 Pin Selection bit (CCP1 function on RB0)
#pragma config CP = OFF         // Flash Program Memory Code Protection bit (Code protection off)
// CONFIG2
//#pragma config FCMEN = OFF      // Fail-Safe Clock Monitor Enable bit (Fail-Safe Clock Monitor disabled)
//#pragma config IESO = OFF       // Internal External Switchover bit (Internal External Switchover mode disabled)

#include <xc.h>
#define _XTAL_FREQ 8000000      // System clock frequency

void main(void) {
 //   OSCCONbits.IRCF = 0b111;        // Set internal oscillator frequency to 8MHz
 //   OSCCONbits.SCS  = 0b10;         // Internal RC is used for system clock
 //    ANSEL = 0x00;                   // Set all I/O to digital I/O
ADCON1= 0x07;
OSCCON = 0x70;
TRISAbits.TRISA0    = 0;        // Set RA0 as output

while(1)
{
    PORTAbits.RA0 = ~PORTAbits.RA0; // Toggle LED pin
    __delay_ms(1000);
}

return;
}

The circuit is just the chip wired to the ICD4 with a 10K pullup resistor on /MCLR, and an LED series with a 220 ohm resistor to pin 17 (port A bit 0). And, of course, a bypass capacitor across the power supply. I set the ICD4 to supply power.

Not sure what could be going wrong in your setup, probably something glaringly obvious (once you see it).

\$\endgroup\$
12
  • \$\begingroup\$ Thanks Spehro...still having no luck. Copied your code verbatim and tried that also. I tried powering the circuit from MPLAB. That seemed to help the debugger. I was able to single-step the assembly to 0x7C9 which was "IORWF TMR1H, F" ... hangs right there every time. So this is progress...looks like the code is trying to run, but something is setup wrong in hardware and/or software to keep it from moving past this. \$\endgroup\$
    – John Nagle
    Nov 3, 2019 at 15:54
  • \$\begingroup\$ Can you step through the code in debug? \$\endgroup\$ Nov 3, 2019 at 15:55
  • \$\begingroup\$ In assembly view, yes...but only until it hits the IORWF instruction at 0x7C9....whereupon it hangs. \$\endgroup\$
    – John Nagle
    Nov 3, 2019 at 16:04
  • 1
    \$\begingroup\$ You need a bypass capacitor across the power supply pins or you'll likely get all kinds of weird stuff happening. Right from pin 5 to 14 with a leaded ceramic capacitor at the chip, though an electrolytic might do for a test. \$\endgroup\$ Nov 3, 2019 at 16:42
  • 1
    \$\begingroup\$ Tested...unfortunately, a variety of capacitors have had no effect. :-( \$\endgroup\$
    – John Nagle
    Nov 3, 2019 at 17:31
1
\$\begingroup\$

Early PICkit 4 models with serial numbers before BUR20* will brick / permanently destroy any PIC requiring a Vpp over 9 Volts. Microchip considers these PIC parts old and not recommended for use in new designs.

The MPLABX release notes also state this, and suggest a 100 Ohm resistor be installed in series with Vpp.

Forum member Howard Long discovered that Vpp was overshooting to 20 Volts without the resistor installed. A high current can result, which destroys the PIC. See his posts with scope captures in the thread "Cannot Program SOIC PIC, but the DIP works fine. PIC16F676, PICKit4 " https://www.microchip.com/forums/FindPost/1084278

Note that the reason PDIPs are less likely to be destroyed than SOICs, is PDIP's inherent greater pin and pad capacitance. Adding 0.1 uF to Vpp pin doesn't seem to interfere with programming, and may be an alternative solution (unverified).

The Microchip document ETN-37 describes a modification of adding a 470 Ohm resistor to the gate of a MOSFET Q4 in the PICit4 (slows the gate voltage rise by using the gate capacitance), but unfortunately gets it wrong both in the text and included photos. For a proper fix, see forum member johnmx's elegant solution in post "ETN #37 - PICkit 4 VPP Overshoot Modification" https://www.microchip.com/forums/FindPost/1148023

The Vpp overshoot problem has supposedly been resolved in newer PICkit 4 models with serial numbers BUR20* and later. ETN-37 was re-released in May 2020 with this updated info.

\$\endgroup\$
0
\$\begingroup\$

It would appear that John Nagle has tried many of the reasonable suggestions to get the circuit to work.

It is perhaps time for a more unreasonable suggestion.

Some of the Microchip controllers that have the Low Voltage Programming feature on a PORT pin such as RB3 will behave erratically when that pin is not pulled down.

Please try using this circuit: enter image description here

\$\endgroup\$
1
  • \$\begingroup\$ Thanks Dan, I will give this a try. I also ordered a batch of 10 PIC16F18344 chips to experiment with. I don't think I've damaged these 3 that I have now, but wanted to see if I had better luck with a different part. Thanks for taking the time to create this, I really appreciate it and I'll let you know if it worked. \$\endgroup\$
    – John Nagle
    Nov 3, 2019 at 23:09
0
\$\begingroup\$

READ PHOTO INCORRECTLY - HAVE EDITED MY ANSWER TO STATE RA0

Looking at the photo you shared on Google Drive, it appears you have connected pin 9 (RB3) and pin 17 (RA0) together. Tying 2 digital i/o pins together might also cause a problem if you tried to use them both for output.

As others have already mentioned, it appears that you are missing a pull-up resistor on MCLR although I think you have since addressed that issue.

void main(void) {
    OSCCONbits.IRCF = 0b111; 
    // Set internal oscillator frequency to 8MHz 
    OSCCONbits.SCS = 0b10; // Internal RC is used for system clock 
    ANSEL = 0x00; // Set all I/O to digital I/O 
    TRISAbits.TRISA0 = 0; // Set RA0 as output 
    TRISBbits.TRISB3 = 0; // Set RA0 as output 
    while (1) { 
        PORTAbits.RA0 = ~PORTAbits.RA0; // Toggle LED pin 
        PORTBbits.RB3 = ~PORTBbits.RB3; 
        __delay_ms(100); 
    } 
return; 
} 

enter image description here

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.