PIC 16F628A Configuration is not blank error

Wond3rboy

Member
Hi, i am trying a simple switch test routine on a 16f628a, the problem is that when i try to program it, it gives a write failed at address 0x0000. When i erase it and do a blank check, it says that configuration is not blank. Is there any remedy for it or this chip is done for.

PS: Chips are not available here locally have to go to karachi to ge them so thats why wanting to get this working.
 
The configuration address isn't a problem... once it's programmed (usually you keep the same config....) The problem is address 0x0000 write failed.. sounds like one of the programming data, clock or Vprog pins have been damaged... How far is Karachi from you.... Have you a reasonable postal service...

Before you condemn the chip... just check the connections...
 
Hi, thanks for your replies guys. Using a Junebug and tried it with MPLab and PICKIT Programmer as well.

@ Ian, Karachi is not that far and some shops have introduced a postal service too. Will ask them to send one over. Just thought i could get it working.

Connections are fine, i am using a breakout board for programming it.

Thanks again.
 
Basically you need a new chip to prove where the fault is - it may well NOT be the chip (they do take some destroying), it's quite possibly a poor connection or a short somewhere in your connections. It sounds like the chip isn't been switched to programming mode?.
 
I have had many PIC16f628a's "lock-up" They simply will not program after a few re-programs. The answer is to use a different programmer.
The actual explanation for this has already been provided on this forum.
 
Hi, i've got another 16f628a thats working just fine, i can program it and all. Trying a tweaked version of nigel's tutorials so needed two. Am going to order them. Thanks for your replies.
 
I have had many PIC16f628a's "lock-up" They simply will not program after a few re-programs. The answer is to use a different programmer.
The actual explanation for this has already been provided on this forum.

To clarify - it's NOT 'locking up' - it's simply been set to use the internal oscillator and for MCLR to be I/O (as my tutorials do). If this is the case then your programmer has to meet specific obvious requirements to access programming mode.
 
The 16F628 and 628A can give programming errors if you don't hold the LVP pin (RB5? i think?) low when programming.

Generally all you need to do is tie the LVP pin low with a 1k resistor.
 
I personally have never had an issue and I never tie the LVP pin to ground at all. I do however always ensure that I have _LVP_OFF in the configuration word.
 
The 16F628 and 628A can give programming errors if you don't hold the LVP pin (RB5? i think?) low when programming.

Generally all you need to do is tie the LVP pin low with a 1k resistor.

Hi, but you dont need to do anything with the LVP pin if you're not using LVP. Like Jon pointed out, i also ensure that LVP is turned off in the config word.
 
Hi Wond3rboy,

As already mentioned, the problem stems from using the internal oscillator and not using MCLR.

The problem is that the program starts running before the programmer can take control of the chip.

You can sometimes get it programmed by shorting MCLR to ground just before you press the program button, and then releasing it shortly afterwards.

So:
> Short MCLR to ground
> Press 'Program'
> Release MCLR

It may take a few times to get the timing right.

In future, if you wish to use internal MCLR and internal oscillator, then insert a delay at the start of your program (right after ORG before the rest of your program) which will allow your programmer to take control of the chip before the program starts.
 
Last edited:
Hi, thanks Gob, i have already dumped that chip. I was replying to Jon about what i understood about LVP. I will be carefull of putting in a delay after the the start of the main routine.
 
Hi, but you dont need to do anything with the LVP pin if you're not using LVP. Like Jon pointed out, i also ensure that LVP is turned off in the config word.

It depends on the system your programmer uses. I've had numerous problems with the LVP pin when there is external hardware that pulls the LVP pin to 5v, as Gobbledok says it depends on the way the programmer handles the MCLR pin and the sequence it uses for full erase, then program after etc. As a general rule it is advisable to have a pulldown on the LVP pin.
 
Oh k. Actually i dont tend to use ICSP for the chips that i program, i have made breakout boards for the interface required to run the controller as well as a programming target board. Thats why i haven't encountered this problem. Thanks for the tip
 
Cookies are required to use this site. You must accept them to continue using the site. Learn more…