16F88 code locking pic ?

[mister_e]

it's probably a JDM or else based programmer.

i do remind an error 0000 or something like that, not sure if the following is what you're looking for
http://www.picbasic.co.uk/forum/showthread.php?t=1915

Basically MCLR voltage wasn't high enough, PGM wasn't tied to GND while programming, the PGC/PGD where much too loaded and/or target supply was noisy. Another thing happened with EPIC without the XP printer poll patch installed

[ruijc]

Hi Mister-e,

It wasnt a low voltage problem.

This one could program any device at any time but with this specific code the pic could no be programed ever again.

I think that was mentioned that the program burned sets some pins in a way that the programming pins cannot be used to re-program the pic.

It was also mentioned that this phenomenon may occour when these pins are programed this way combined with using the internal oscilator.

.

[ruijc]

Ok...i think i found it...

Quote "If you've programmed the PIC so that it uses the internal oscillator AND have programmed the MCLR pin as an IO you'll have this problem. This is because the programmer will no longer be able to reset the PIC or stop the oscillator before entering programming mode."

http://www.electro-tech-online.com/m...ills-pics.html

Is this valid for any pic that supports these features ??

EDIT: It also says that you can still program it anyway...
.

[nomad]

Snipped from web:

I believe that the "JDM Programmer" is cheap and very useful PIC Programmer. However, since "JDM Programmer" cannot control VDD, the algorithm "VPP before VDD" is inapplicable. Programming to the latest device from this reason may go wrong when using CONFIG settings as "Internal oscillator" "MCLR OFF".

I've seen that, it's a downfall of a basic JDM style programmer.

The jdm always supplys power and cannot bring VPP high before powering the pic.
(This is how to get to programming mode with MCLR disabled).

I use a newer JDM style programmer that doesn't have this problem.
I use 16f88's (628a, 648a) with intosc and mclr off, without any problems.
Was one of the first things I tested with the "enhanced jdm" programmer.

Other programmers don't have this problem, the pic CAN be re-programmed.
(just not with a cheapo JDM)

[tenaja]

MELabs actually helped me solve this issue over the phone.

If you use MCLR as an input pin, then you need to delay at least two seconds before configuring the osc drive... these are notes I made in my code... and they work.


' Turn PGC (PORTB.6) & PGD (PORTB.7) into inputs (tris.x =1)
' Disable hardware Crystal drive
' Pause ~2 seconds.
' This allows the PIC to reset for programming. Otherwise, it's a hit & miss for programming.

[ruijc]

Tenaja,

this means i have to always ( everytime i use internal oscillator AND have programmed the MCLR pin as an IO ) include a small code before the actual code, right ?



BeforeCode:

input portb.6 ' Turn PGC (PORTB.6) & PGD (PORTB.7) into inputs (tris.x =1)
input portb.7 ' Turn PGC (PORTB.6) & PGD (PORTB.7) into inputs (tris.x =1)

' Disable hardware Crystal drive -> What is the simplest way to do this ?

pause 2000 ' Pause ~2 seconds

Codestart:

' and here starts the program

.

[tenaja]

No, it's not when using the internal osc.

It's when using the internal osc, but the external osc driver as an interrupt... I'm using it with a 32khz crystal for RTC functions, but running the PIC off of the internal 8mhz osc.

If you aren't using the mclr as an input (you are leaving it open for mclr use) then you have nothing to worry about. It is only if you are using the mclr as something out of the ordinary. It has to do with the mclr pin allowing it to reset the pic to allow reprogramming.