Daz said:Hi all,
I am new to the world of PICs (love em!). I got my first 16F84 and made a programmer for it last month. Worked great so I ordered 5 more. This time they are the 16F84A-20/P model.
Of the 5, I am only able to program 2 of them. The other 3 are coming up with verify errors. Is it common to receive bad chips (3 out of 5 no less)? Or could there be something I'm doing wrong?
I'm using the Winpic Programmer and a home-built JDM (Serial) type of programmer. As I say, I can succesfully burn 2 of them, so I'm sure there's no problem with the programmer or software.
Thanks for any ideas you may be able to offer.
Daz
Daz said:The other 3 are coming up with verify errors. Is it common to receive bad chips (3 out of 5 no less)? Or could there be something I'm doing wrong?
eblc1388 said:Take note of the errors. Do the verify errors all at Address 0000 or they occured in later addresses but in random locations different each time?
Do a manual erase and then program. If you get verify errors then erase and program again. Does the error occurs at the same place?
With NO PIC in the socket, do a program run and measure Vdd voltage(between pin 5 and pin 14). Is it anywhere near 4.8V - 5.2V?
Do another program run and measure MCLR/VPP voltage(pin 4 and pin 5) at the socket. Is it anywhere near 12V-13V?
Now check again with a PIC in the socket, does the above voltages drops lower a lot?
Daz said:1) I'm getting 5.13V at Vdd
2) I'm getting 13.56V at MCLR/VPP
Neither one change with a chip in the socket.
Daz said:I'm getting verify errors in the same place every time. In fact, when I do an erase, none of the data is changed.
I know this because now 4 of the 5 PICs aren't working. 2 Were working at first, and I loaded a program into one and it stopped working shortly after that. The program is still in the PIC and I can read it through the JDM but when I do a BULK Erase and re-read, the program is still there. So erase and write operations are not getting through to these 4 out of 5 chips. One chip is still working great.
Also my older 16F84 (Non A) chip is still working fine.
Daz said:A note, these 5 new chips are all 20 Mhz versions, so I wonder if they are more picky than my 4Mhz version.
Daz said:Any suggestions of a good programmer schematic I might try to replace the JDM? I'd like to keep it RS-232 if I can and also simplicity is my preference.
Daz said:Or do you think I'm better off getting in 5 new 16F84 - 4Mhz chips?
eblc1388 said:Don't buy any more of 16F84 or 16F84A. They are old and expensive. A new PIC 16F628A has twice the program memory and cost much less.
The only reason of people buying 16F84 or 16F84A is the object code requirement. A program assembled for 16F84/A will not work on another PIC unless one has the source code, changes a few memory locations and reassemble.
Hey, mine tooeblc1388 said:My first PIC programmer though is a form of JDM design called RCD programmer. It works with no major issues.
eblc1388 said:Try connects the Pin16 RA7 to Vss(pin5) and see if situation improves. This is the internal RC oscillator input in case you have enabled it.
eblc1388 said:Glad to hear there is at last some good news.
The voltage drop is normal as you are supposed to test the signal line one by one.
Can you try changing these options to see whether it helps?
Nigel, I don't want this to sound rude, but you are wrong about the 84->628 code transition. Don't forget that 628's SFR and GPR's have different boundaries, and the 84 program wouldn't work correctly on 628 !!! So it is important to move all GPRs 20 memory locations lower (and also turn off Comparators as suggested). Or I am wrong :?:Nigel Goodwin said:eblc1388 said:Don't buy any more of 16F84 or 16F84A. They are old and expensive. A new PIC 16F628A has twice the program memory and cost much less.
The only reason of people buying 16F84 or 16F84A is the object code requirement. A program assembled for 16F84/A will not work on another PIC unless one has the source code, changes a few memory locations and reassemble.
I agree fully, you SHOULDN'T be buying 16F84's, they were replaced by the better, cheaper, 16F628 last century!.
Even if you only have a HEX file it's not a problem, load the HEX file into my programmer software WinPicProg and disassemble it, add the two extra lines to disable the comparators (which the 16F84 doesn't have), set the fuses how you want, and reassemble it using MPASM. There's hardly any changes required, and MicroChip have a 'migration document' on their website that explains everything.
Check my tutorials, which mostly use the 16F628.
Jay.slovak said:Nigel, I don't want this to sound rude, but you are wrong about the 84->628 code transition. Don't forget that 628's SFR and GPR's have different boundaries, and the 84 program wouldn't work correctly on 628 !!! So it is important to move all GPRs 20 memory locations lower (and also turn off Comparators as suggested). Or I am wrong :?:Nigel Goodwin said:eblc1388 said:Don't buy any more of 16F84 or 16F84A. They are old and expensive. A new PIC 16F628A has twice the program memory and cost much less.
The only reason of people buying 16F84 or 16F84A is the object code requirement. A program assembled for 16F84/A will not work on another PIC unless one has the source code, changes a few memory locations and reassemble.
I agree fully, you SHOULDN'T be buying 16F84's, they were replaced by the better, cheaper, 16F628 last century!.
Even if you only have a HEX file it's not a problem, load the HEX file into my programmer software WinPicProg and disassemble it, add the two extra lines to disable the comparators (which the 16F84 doesn't have), set the fuses how you want, and reassemble it using MPASM. There's hardly any changes required, and MicroChip have a 'migration document' on their website that explains everything.
Check my tutorials, which mostly use the 16F628.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?