16F883 Code Verify Problem

[munromh]

I'm having a "code verify error" pop up when I program a 16F883 chip. I'm using a Melabs U2 programmer, PBP, and Microcode Studio. I only have VDD (+5VDC), VSS, ISCPDAT, ISCPCLK, and /MCL (pulled high via 10k) connected. I was previously using a 16F648A & 16F627A, the 16F648A was still setup so I tried programming that and all was fine. I tried a second 16F883 chip, no luck. I read the chip after a program cycle and looked at the memory; it looks like it doesn't program the first four words, programs the next four words, repeat:

Top block = program code
Bottom block = chip memory read after program cycle

http://www.soundunderwatersurvey.com/Downloads/Web_references/16f883,_code_verify.jpg

I didn't find any relevant data in a forum search.

I've use ISCP on a number of other chips ....

Bad chip lot? I'm not seeing a small subtlety in the data sheet?

Any ideas?

Thanks,
Mark

[Darrel Taylor]

What version of meprog do you have?

There were some fixes for the 88x family in V4.21
<br>

[hatchethand1000]

I have been having the same issues with the same processor. 16F883, PBP 2.50b, and the USB programmer on ver 4.21.

What I discovered over the last 36hrs:
I make a code change in the program, compile and then write it to the processor. Then upon testing the change I find it get the same results as if I made no code change. VERY frustrating.

After a while (5 days) I thought I was losing my mind, I decided to put an old program into the chip to see what was happening. And I discovered the update did not get into the chip even though it verified the program after writing.

I went to a program that was months old(just the hex file no re-compile), that I knew did not work, and pushed it out to the 883. To my amazement it went to the chip, then I was able to push my latest code (with re-compile) out and it too worked.

What the issues seems to be so far, after calling MELabs and ordering an new programmer which did not help. They said their hardware was probably not the issue. And they were correct.

Guess#1:
The default installation path for PBP is very long in characters and you get close to the 62 character max for compiling if you give your revisions any detail at all, so you the path described in PBP needs to be verified. If you created a mapped drive to the default MCS directory that might be the issue?

I have no idea if that is the issue but now I push done the dummy hex file every few re-programs if I have any doubt if the programmer or PicBasic Pro is passing the hex file correctly to the programmer.

My new programmer came with the updated 4.24, so I updated my old programmer and put the new one on the shelf.

Somehow the new hex file is not getting to the programmer software or to the directory and the programmer is pushing down the previous code, which is why I am getting a good verify.

Kevin

[munromh]

What version of meprog do you have?

There were some fixes for the 88x family in V4.21
<br>


I had V4.20, I now have V4.24 beta and all is good.

I also upgraded my Microcode Studio and I'll now look at my PBP version level.

Thanks yet again,
Mark

[munromh]

I have been having the same issues with the same processor. 16F883, PBP 2.50b, and the USB programmer on ver 4.21.


I believe I had a similiar issue when I started trying to save files in directories other then the default dir under Mecanique/MCS. I now just use the default directory and move them around when I'm done. Now that my software revision levels will be up to date maybe I can look at that again.

Mark