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

Discussion in 'Embedded Systems and Microcontrollers' started by PDubya, Feb 7, 2007.

  1. PDubya

    Thread Starter Member

    Mar 16, 2006
    28
    0
    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!!!
     
  2. n9352527

    AAC Fanatic!

    Oct 14, 2005
    1,198
    4
    Check whether the MCLR internal pull-up is enabled in your fuse settings. If so disable it and try again.
     
  3. PDubya

    Thread Starter Member

    Mar 16, 2006
    28
    0
    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...

    Code ( (Unknown Language)):
    1.  
    2. ; ===============================
    3. ; Setup ASM
    4. ; ===============================
    5.     LIST    p=16F628        ;tell assembler what chip we are using
    6.     include "P16F628.inc"        ;include the defaults for the chip
    7.     __config 0x3D18            ;sets the configuration settings (oscillator type etc.)
    8.  
    9.     cblock     0x20             ;start of general purpose registers
    10.         count1             ;used in delay routine
    11.         counta             ;used in delay routine
    12.         countb             ;used in delay routine
    13.     endc
    14.  
    15.     LEDPORT    Equ    PORTB        ;set constant LEDPORT = 'PORTB'
    16.     LEDTRIS    Equ    PORTB        ;set constant for TRIS register
    17.     SWPORT    Equ    PORTA        ;set constant SWPORT = 'PORTA'
    18.     SWTRIS    Equ    PORTA        ;set constant for TRIS register
    19.    
    20.     ; ===============================
    21.     ; set constants for the switches
    22.     ; ===============================
    23.     SWFOOT    Equ    7        ;foot switch
    24.     SWRESET    Equ    6        ;back reset switch
    25.     SWTEST  Equ     5        ;internal test switch
    26.    
    27.     ; ===============================
    28.     ; set constants for the outputs
    29.     ; ===============================
    30.     LEDB0    Equ    0        ;blink port 1
    31.     LEDB1    Equ    1        ;blink port 2
    32.     LEDB2    Equ    2        ;blink port 3
    33.     LEDB3    Equ    3        ;blink port 4
    34.     LEDPWR    Equ    7        ;power led
    35.     BUZZER    Equ    6        ;buzzer    
    36.    
    37.     org    0x0000            ;org sets the origin, 0x0000 for the 16F628,
    38.                     ;this is where the program starts running    
    39.     movlw    0x07
    40.     movwf    CMCON            ;turn comparators off (make it like a 16F84)
    41.  
    42. ; ===============================
    43. ; Initialize Ports
    44. ; ===============================
    45.     bsf     STATUS,    RP0        ;select bank 1
    46.     movlw     b'00000000'        ;set PortB all outputs
    47.     movwf     LEDTRIS
    48.    
    49.     bcf    STATUS,    RP0        ;select bank 0
    50.     clrf    LEDPORT            ;set all outputs low
    51.    
    52.     movlw     b'11111111'        ;set PortA all inputs
    53.     movwf     SWTRIS
    54.  
     
  4. n9352527

    AAC Fanatic!

    Oct 14, 2005
    1,198
    4
    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.
     
  5. PDubya

    Thread Starter Member

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

    AAC Fanatic!

    Oct 14, 2005
    1,198
    4
    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
     
  7. PDubya

    Thread Starter Member

    Mar 16, 2006
    28
    0
    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.
     
Loading...