Unable to re-program 16f628a once "blink"-ed

Thread Starter

PDubya

Joined Mar 16, 2006
28
So, I pulled out my trusty JDM PG2C I nabbed from Sparkfun a few months back to work on a little project, and it doesn't seem to be behaving. Not sure if it matters, but I'm using icprog to program through the JDM.

I know I've programmed from my machine before with this same configuration without issue, but now I'm constantly getting the ever so lovely 0000h error and have no idea why.

I thought the old chip I had on the breadboard might be buggered up. So I pull another one from an old socket on a project board, still can't program or even read it. Thinking maybe both are goobered, I pull a new one out of the tube, plug it in, and download blink.hex for the 628a from sparkfun, and it programs! Test it, and it works fine. So I try and re-program it with my test program, and I get 0000h errors.

I've tried ICP, and even plugging the chip directly into the programmer, no avail. Just 0000h errors. I don't want to keep popping new chips in the programmer as I only have a couple new ones left, but this is really frustrating.

---

After some additional troubleshooting, the only thing I can think of is that the test program is somehow interfering with the program/erase of the pic once it's been programmed. But I'm really clueless, this is only a shot in the dark.

I can't even erase a chip, as after it goes through the erase cycle on the programmer, it's still running the test program.

... any suggestions would be greatly appreciated. Thanks!!!
 

Thread Starter

PDubya

Joined Mar 16, 2006
28
I found this article on microchip's site.

They mention programming a delay at the beginning of your program. Where exactly are they referring to? Here's the top part of my current code...

Rich (BB code):
; ===============================
; Setup ASM
; ===============================
    LIST    p=16F628        ;tell assembler what chip we are using
    include "P16F628.inc"        ;include the defaults for the chip
    __config 0x3D18            ;sets the configuration settings (oscillator type etc.)

    cblock     0x20             ;start of general purpose registers
        count1             ;used in delay routine
        counta             ;used in delay routine 
        countb             ;used in delay routine
    endc

    LEDPORT    Equ    PORTB        ;set constant LEDPORT = 'PORTB'
    LEDTRIS    Equ    PORTB        ;set constant for TRIS register
    SWPORT    Equ    PORTA        ;set constant SWPORT = 'PORTA'
    SWTRIS    Equ    PORTA        ;set constant for TRIS register
    
    ; ===============================
    ; set constants for the switches
    ; ===============================
    SWFOOT    Equ    7        ;foot switch
    SWRESET    Equ    6        ;back reset switch
    SWTEST  Equ     5        ;internal test switch
    
    ; ===============================
    ; set constants for the outputs
    ; ===============================
    LEDB0    Equ    0        ;blink port 1
    LEDB1    Equ    1        ;blink port 2
    LEDB2    Equ    2        ;blink port 3
    LEDB3    Equ    3        ;blink port 4
    LEDPWR    Equ    7        ;power led
    BUZZER    Equ    6        ;buzzer    
    
    org    0x0000            ;org sets the origin, 0x0000 for the 16F628,
                    ;this is where the program starts running    
    movlw    0x07
    movwf    CMCON            ;turn comparators off (make it like a 16F84)

; ===============================
; Initialize Ports
; ===============================
    bsf     STATUS,    RP0        ;select bank 1
    movlw     b'00000000'        ;set PortB all outputs
    movwf     LEDTRIS
    
    bcf    STATUS,    RP0        ;select bank 0
    clrf    LEDPORT            ;set all outputs low
    
    movlw     b'11111111'        ;set PortA all inputs
    movwf     SWTRIS
 

n9352527

Joined Oct 14, 2005
1,198
Ah, yes. The other internal MCLR issue. This is actually similar to the internal MCLR pull-up issue. These issues only happen with badly designed programmer (i.e. cheap and nasty :D), including Microchip's own ICD2. The reasons are the MCLR and Vcc controls are badly implemented.

Other than not using the internal MCLR and internal oscillator or internal MCLR pull-up in your fuse settings, putting a big delay at the start of your program will also help. Just put the delay right after the .org and it should be fine.

For the chips that had already been programmed, I found that holding MCLR low manually (I used a piece of grounded wire and a 100 ohm resistor in series) and then taking it off right after pressing the program button does wonder. You might have to try this a few time to get the timing right. The idea is to keep the PIC from starting right before the programming sequence activate itself.

Another way is to buy a robust professional programmer, which could be expensive just to salvage a few chips.
 

Thread Starter

PDubya

Joined Mar 16, 2006
28
Holy cow that grounding MCLR trick totally worked! Would just shying away from even using the RA5 pin help with this at all?
 

n9352527

Joined Oct 14, 2005
1,198
No. The root causes are the internal MCLR pull-up and internal RC oscillator fuse settings. When you use internal MCLR (no external hardware to reset the PIC on power up), then the MCLR is pulled-up to Vcc internally after some pre-determined time after the internal RC oscillator is stable. This means that the PIC would start by itself some time after Vcc is applied.

Cheap programmers usually dispense with or badly implement the Vcc control or robust Vpp/MCLR low voltage. So they supply Vcc too early and also they don't have the capability to pull the MCLR down to prevent the PIC from starting up. So the PIC starts to do it's own thing and just ignore the programmer.

Just keep that piece of wire handy :D
 

Thread Starter

PDubya

Joined Mar 16, 2006
28
Thanks again! Guess I'll live with the old wire trick ;). It's crazy this was so hard to figure out. I'm surprised you don't hear about it more often.
 
Top