• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

PICkit3 not programming

Status
Not open for further replies.

thecritic

Member
I just got PICkit3 from sure electronics, PICKIT 3 & MCU Universal ZIF socket for PICkit 2 or 3 Free shipping_Programmers_Development Boards_MCU Development Boards and Modules_Sure Electronics' Webstore

When I tried to programm 16f877A by using Mp-lab ide, it connects to the device and retrieves Id. But when I try to program I get the following error.
------------------------
PICkit 3 detected
Connecting to PICkit 3...
Firmware Suite Version...... 01.26.05
Firmware type......................Midrange
PICkit 3 Connected.
Device ID Revision = 00000008

Programming...
The following memory regions failed to program correctly:
Program Memory
Address: 00000004 Expected Value: 000000fd Received Value: 00003fff
Programming failed
----------------------------------
Few things to consider:
1.I was able to program 16f676 with a separate program.
2. I have already fooled with the 16f877A pic which I am trying to program with un-working jdm programmes, , so may be I have made code-protect or like.
3. I am powering the divice by pickit3 (since no peripheral connected ) and getting Vdd 4.63 Volts.

What should I be doing now?
 

thecritic

Member
yeah, there was problem with config. Now it successfully programs/verifies and reads. cheers. But I am again put down.
The PIC don't startup. I programmed a simple led-flashing (high tech C), it simulates well (proteus vsm, isis) but in real hardware it don't do anything. I tried both RC and HS oscillator, but no luck.
I am dead sure the PIC is programmed correctly. I can even read all programs back.
Seems like problems with oscillator.
And yeah, I have tied MCLR to Vdd with 3.3 K.
For HS, used: 12.0 Mhz crystall and 22 pf caps
for RC used, 3.3 K Resistor and 22 pf Caps.
Connection as shown in datasheet.
 

AtomSoft

Well-Known Member
Isis shows everything slower than real time really so be aware your delays may be too fast perhaps? post code and schematic for better help
 

thecritic

Member
Using Hi-tech C complier and Mplab ide. Set Device as 16f877A.
------------------------
#include<htc.h>

__CONFIG(DEBUGDIS & HS & WDTEN & PWRTEN & BORDIS & LVPDIS); // here ; must be used
#define _XTAL_FREQ 20000000

#define Output PORTD
#define Out 0x00
#define In 0xFF

void main(){

TRISD = Out;
Output= 0xbc;
__delay_ms(15);
while(1){
Output ^= 0xff;
__delay_ms(15);
__delay_ms(15);
__delay_ms(15);
__delay_ms(15);
__delay_ms(15);
__delay_ms(15);
__delay_ms(15);
__delay_ms(15);
__delay_ms(15);
}

}
------------

For the schematic;
1. Tied mclr to vdd with 3.3k resistor.
2. connected crystals and capacitor in osc1 and osc2. (obvious)
3. conected led to pin 21, 22, etc.

and one thing:
I have connected the same crystal/caps to in 16f676, it works there.
 
__CONFIG(DEBUGDIS & HS & WDTEN & PWRTEN & BORDIS & LVPDIS); // here ; must be used
You have the WDT enabled like I thought. So instead of WDT_OFF, its WDTDIS for Hi-tech I guess.

When the watchdog timer is enabled, by default, it will reset the PIC device roughly every 18ms. So the code example above has no chance to experience meaningful on and off periods.

Also you might want to change the Output ^= 0xff; statement, as it will always be off in the while(1) loop.

Code:
Output ^= 0xff;

TO:

Output ^= Out;
There is a valuable guide for the mid-range PICs that can be found on the Microchip site. Search for the "PICmicro™ Mid-Range MCU Family Reference Manual".
 

thecritic

Member
-----------------------------------
#include<htc.h>

__CONFIG(HS & WDTDIS & PWRTEN & BORDIS & LVPDIS); // here ; must be used
#define _XTAL_FREQ 20000000

#define Output PORTD
#define Out 0x00
#define In 0xFF

void main(){

TRISD = Out;
TRISB = 0b11001001;
Output= 0xbc;
__delay_ms(15);
while(1){
Output ^= 0xff;
PORTB ^= 0b00110110;
__delay_ms(15);
__delay_ms(15);
__delay_ms(15);
__delay_ms(15);
__delay_ms(15);
__delay_ms(15);
__delay_ms(15);
__delay_ms(15);
}
}
--------------------------------------
changed the program, disabled the wdt. Used another port, port B. Now I am using led in rb5. But still no luck.
-----------------
Output ^= 0xff
does bitwise XOR; so every bit is toggled. 1 XOR 1 = 0; 0 XOR 1 = 1;
-------------------

And I always check by wring the led both ways. So, always 1 or always 0 pin can be detected. In my case, the ports are tristate.
 
Both grounds need to be tied together, same for V+. Running out of ideas. Last shot would to make sure there is also a 0.1uf bypass cap across Vdd and Vss next to the chip. To be sure MCLR is not a problem, disable it in config. Verify voltages with DVM, check for any solder bridges if on protoboard. Good luck.
 

thecritic

Member
After a bit search, I am now sure that the oscillator is not starting. The voltage at osc1 pin is near 0 and at osc2 is 5V. I have come to know that it should be around 1-3 volts.
What are the things that may prevent oscillator from starting apart from damaged PIC/crystal/caps ?
The PIC (877A) still doesn't run even if I apply pulses to its osc1 by using another PIC (676).
Yeah, MCLR is neatly tied to Vdd.
 

mvs sarma

Well-Known Member
As suggested by nickelflippr, loop Vdd1 to Vdd2 , and Vss1 to Vss2. provide 0.1(100nF or 104) disk cap cross . check with another crystal. keep the paths of caps 22pF to ground as short as possible.

As you said you have programmed with some JDM, better to completely erase the chip once.
if you intend to blink a LED, perhaps the delay is barely sufficient to see with bare eye.
so increase the delay to 100mS ON and 100mS off. all the best.





http://www.electro-tech-online.com/members/nickelflippr.html
 

thecritic

Member
Both Vdds and Vss are tied together.
Checked with multiple crystals.
Chip is completely erased and reprogrammed.
It verifies well.
caps well placed.

Now I am in the thought that the Chip is already damaged. I will buy another and check with it.
But seeing that the chip is neatly programmed and verrified, its hard to believe its damaged.
 

mvs sarma

Well-Known Member
remove the 100uF and have only 104 capacitor. use three dry cells and try to work at 4.5V DC instead of adopter. upload the hex file, let us see

Though I am not into C, Try to compile attached file and check .
 

Attachments

Last edited:

thecritic

Member
Add 104 cap. Used 12 V battery + 7805 steady 5 volts. and switched to assembly
-----------------

list p=16f877A ; list directive to define processor
#include <p16f877A.inc> ; processor specific variable definitions

__CONFIG _CP_OFF & _WDT_OFF & _BODEN_OFF & _PWRTE_ON & _HS_OSC & _WRT_OFF & _LVP_OFF & _CPD_OFF


ORG 0x000
goto main
main
bsf STATUS, RP0
movlw b'11001001'
movwf TRISB
bcf STATUS, RP0
clrf PORTB
nop
nop
nop
nop
comf PORTB, f

goto main

END
----------------------------

I know the blinking is way too fast. But it should glow in half brightness anyway.
Moreover, the problem is the oscillator isn't starting in the first place (confirmed by measuring voltage)
 

tunedwolf

Well-Known Member
I have found time after time that 22pF is sometimes a little light for some Crystals to reliably start oscillating, I usually opt for 33pF. Most Crystal manufacturers will quote capacitive loading test figures to you under perfect conditions, but in the real world, it depends on your board layout, trace lengths/ widths and lead lengths etc. Crytals can be pulled only so far before they just refuse to oscillate. I would suggest that you remove the Crystal and 22pF caps and replace them with a three terminal ceramic resonator of a reasonable frequency, say 4Mhz for testing purposes. Also in your schematic you show the 22pF caps returning to the VSS pin, if this is indeed the case, remove the connection and give them their own return path to ground because this can often lead to oscillator instability due to power supply ripple and noise, although at less than 20Mhz it's unlikely to be the cause of your trouble, but why give yourself a headache later trying to debug a flaky clock...

rgds

Here is a wee piece of code that I quickly knocked up, it has not been tested, so don't shoot me if it doesn't work exactly as intended :)

Code:
;*****************************************************************
;*This program attempts to flash an LED at approx 1 sec intervals*
;*The program uses the Prescaler, Timer0 and a File Register     *
;*called Clock_Divisor located at 20h                             *
;*                                                                 *
;*Target:            PIC16F877A                                     *
;*Ver:                1.00                                         *
;*Author:            Tunedwolf                                     *
;*Date:                30/01/2011                                     *
;*****************************************************************

list p=16f877A ; list directive to define processor

#include <p16f877A.inc> ; processor specific variable definitions

__CONFIG _CP_OFF & _WDT_OFF & _BODEN_ON & _PWRTE_ON &_HS_OSC & _WRT_OFF & _LVP_OFF & _DEBUG_OFF & _CPD_OFF


;EQUATE TABLE

CLOCK_DIVISOR EQU H'20'    ;ASSOCIATE CLOCK DIVISOR WITH REGISTER 20H


;CODE STARTS HERE

ORG H'00'                ;RESET VECTOR
GOTO INIT                ;JUMP TO INIT AND BEGIN EXECUTION

ORG H'04'                ;INTERRUPT VECTOR
BCF INTCON, TMR0IF        ;CLEAR TIMER0 OVERFLOW INTERRUPT

DECFSZ CLOCK_DIVISOR    
RETFIE                    ;RETURN TO MAIN LOOP

MOVLW H'0F'
MOVWF CLOCK_DIVISOR        ;RESET CLOCK PERIOD DIVISOR

BTFSS PORTB, 5            ;TEST IF LED IS ON OR OFF (PORTB PIN 5)
GOTO LED_ON                ;IT'S OFF, TURN IT ON

LED_OFF:
BCF PORTB, 5            ;IT WAS ON, TURN IT OFF
RETFIE                    ;RETURN TO MAIN LOOP

LED_ON:
BSF PORTB, 5            ;IT WAS OFF, TURN IT ON
RETFIE                    ;RETURN TO MAIN LOOP


INIT:

BSF STATUS, RP0            ;SET BANK BIT

MOVLW H'C7'                ;ASSIGN PRESCALER TO TIMER0 WITH VALUE CLK/256
MOVWF OPTION_REG        ;AND SET THE OPTION REGISTER

MOVLW H'DF'                ;SET MASK FOR PORT PINS TO USE AS OUTPUT (BIT 5)
MOVWF TRISB                ;AND APPLY TO PORT DIRECTION REGISTER

BCF STATUS, RP0            ;CLEAR BANK BIT

CLRF PORTB                ;CLEAR JUNK ON PORT

MOVLW H'0F'                ;SET DIVISOR
MOVWF CLOCK_DIVISOR        ;STORE IN CLOCK DIVISOR SCRATCH 

CLRF TMR0                ;CLEAR TIMER0
MOVLW H'A0'                ;MASK GLOBAL AND TIMER0 OVERFLOW INTERRUPTS
MOVWF INTCON            ;AND APPLY

LOOP:

NOP
GOTO LOOP                ;GO ROUND AND ROUND FOREVER

END                        ;OBVIOUS, BUT WORTH A MENTION
 
Last edited:

mvs sarma

Well-Known Member
the Op is perhaps unable to start the oscillator and he used the same 20MHz and 22pF with another chip where it was oscillating.
I only fear, whether his chip is 16F877-10 and he is trying with 20MHz crystal !!
perhaps better he can try with a 10 MHz crystal to be sure.
 

thecritic

Member
No and No, unfortunately. its pic16f877A - I/P. and further more I already tried with assortments of crystals, from 32 Khz to 20Mhz, from R/C oscillator to external clock input. In every case the chip simply refuses to start-up. Its dead man.
 

Noggin

Member
I have found an issue using a PICkit2 vs a REAL Ice in which the programs written to the chip were different depending on which programmer I used. Both devices programmed and verified using the same .hex file, but the PICkit2 wrote the configuration bits differently. The bits that the PICkit2 wrote differently were "unused" and it wrote them as 0's, but it kept the oscillator from starting.

This is the procedure I did when testing it:
1. Opened MPLAB
2. Selected my MCU
3. Selected PICkit2 as programmer
4. Imported my hex file
5. Programmed the chip
6. Read program back off of chip
7. Exported program to file
8. Closed MPLAB

I repeated the above steps using a REAL Ice. When I did a compare of the two programs, the config bits were different. I then used the PICKit 2 to program in the hex file I read back usng the REAL Ice and the program worked. I programmed the MCU using the REAL Ice and the program I read back off using the PICkit2, and the program failed.

What I learned from this scenario is that you can NOT place 100% faith in the verify step. Just because it verifies doesn't guarantee that the program was written to flash correctly.

I also have another program that had a 100% verification failure rate, but programmed every time. It was also due to the configuration bits. An unused config bit was always read back as 0, but HiTech's config defines didn't write it to 0 so I had to do it myself.

What I learned from this scenario is that you can NOT place 100% faith in the verify step. Just because it doesn't verify it doesn't guarantee that the program was written to flash incorrectly.

In other words, I strongly suggest that you read the flash back out of the program and do a file comparison between the two (the compiler generated .hex file and the one you read back out). Pay special attention to the configuration bits.
 
Status
Not open for further replies.

Latest threads

EE World Online Articles

Loading
Top