12F675 won't reprogram or erase

[Ron Marcus]

Yes the clock & data pins definitely matter if you program in-circuit. A load on the clock pin in particular will really mess with timing.

Read Microchips' DS91017B ICSP guide for a detailed explanation.

I had the same issue rear it's ugly head some months back. If your code is evolving, you really should keep MCLR as a reset. The last programming action will be to flip the config fuse for the MCLR pin to become an input. If you place a 1 K resistor between the clock pin and the circuit it is attached to, this will help. Same with Data pin. For ICSP, I raise the pullup resistor to MCLR to 22K. It helps when your power supply is 2 to 3 volts and the programming power is 5 volts. If that's not enough, a schottky diode from B+ to the VDD pin will allow ICSP in a circuit that can't take 5 volts. I fried come 3 volt comm chips this way before the stupid light went off!
I perconally traded the 12F series for the 16F690 in the 4 mm package. 18 GPIOs and 4 K of flash memory!Boy is this living!

[modifyit]

Well I figured out the issue, not the solution but the issue.

I completely isolated the chip and it would still not program so, I went ahead and replaced the chip and it programmed fine. I got pin GP.2 blinking an LED so that was successful.

Still leaving the MCLR, ICSPDat and ICSClk isolated I decided to try and toggle pin GP.1

As soon as I do this the my MELabs throws a Config error while programming and the chip becomes useless, no programability or eraseability just like my first post.

Any clue why the board is doing this? Here is a snipit of my code

[code\]
DEFINE OSCCAL_1K 1
' Config Fuses
@ __config _INTRC_OSC_NOCLKOUT & _CPD_ON & _CP_ON & _BODEN_ON & _MCLRE_OFF & _PWRTE_ON & _WDT_ON

' Variable Definitions
LED VAR GPIO.1

blink var bit


CMCON=7
TRISIO=%11111001 ' Input 0,3,4,5 Output 1,2
ANSEL=0

Main:
blink=blink+1
led=blink
pause 100
goto main

[\code]


If I change this code to apply to pin GP.2 it works fine and will reprogram all day long

Thanks for any help

[modifyit]

Just killed another one, here is the error thrown by MELABS

"Configuration Error at 0000, 0000 should be 004C. Continue verifying?"

Thanks again for any thoughts...btw when programing the chip the program works, just throws that error when "verifying" and then won't program or erase

[modifyit]

I just got a note back from MELabs stating that you can not reliably program the 12F675 when using both MCLR as an input and the internal oscillator.

I guess I will try making the MCLR as a reset pin later and see if another chip bites the dust.

[mister_e]

probably but as i've tons of design who use internal OSC and MCLR as i/o, i'll probably mostely bet on the CodeProtect stuff. Sure you can reprogram but can't read back. This is probably why you got this error.

ALSO, you may look at the programming sequence and idle state. Some design may ruine your life when using ICSP. Same thing for some device programmer... like PICSTART wich is still great but sometimes a pain in ICSP.

How about doing another test... remove any load on ICSPdata, ICSPClk, and place a 10K pull-up + diode on MCLR pin like...http://www.melabs.com/support/icsp.htm


Then now, remove your code protection (CP and CPD), program ir, erease it. Once done, place your load on ICSPdata, ICSPclk and redo the same... about now??? If problem persist, how about if you shut down the unit, connect it to your programmer, the power-up the unit?

Now do the same thing with the MCLR. About now?

Set your code protect.... aboout now?

[Ron Marcus]

I just got a note back from MELabs stating that you can not reliably program the 12F675 when using both MCLR as an input and the internal oscillator.

I guess I will try making the MCLR as a reset pin later and see if another chip bites the dust.

I repeat...

<<If your code is evolving, you really should keep MCLR as a reset. The last programming action will be to flip the config fuse for the MCLR pin to become an input.>>

[Ron Marcus]

Let's try that again...

If your code is evolving, you really should keep MCLR as a reset. The last programming action will be to flip the config fuse for the MCLR pin to become an input.

[modifyit]

Ahh that could make some sense then...If the last thing the programer does is flip the MCLR to being an input, that is why it could be crashing the MELABS programmer and corrupting the chip, but the chip's program seems to run fine.

I will try using the MCLR as a reset and see what happens.

Thanks again