Erratic programming of 16F870
Posted: 14 Nov 2011 12:44
I'm using an S4 (sn 026980) with a PIC16 adaptor and PIC firmware 2.43 or 2.99 and trying to program a PIC16F870-I/SP. It's in the top end of the ZIF40 socket.
Sometimes it works. Other times it fails to verify, claiming all ones (3FFF), on a PIC that subsequently programs and works fine. Other strange effects are:
(these demonstrated with firmware 2.43, though the same happens with 2.99)
Do ERASE then TEST and then sometimes comes up with CODE PROTECT ON
If I try to burn, doing the following in sequence:
LOAD then EDIT shows the PIC contains all zeroes.
TEST says CODE PROTECT ON
ERASE proceeds without error.
TEST says CODE PROTECT ON
Download an image with RECEIVE INTEL, EDIT shows the hex file has come down fine.
BURN proceeds as normal, then verify fails:
0000 RAM=2844 ROM=3FFF
and so on for every location
LOAD then EDIT shows the PIC apparently still contains all zeroes and TEST shows CODE PROTECT still ON.
Sometimes it can be made to work by changing the device type and then changing it back again and reconfiguring the PIC, but this is by no means guaranteed. It still shows the same behaviour even if the PIC is completely removed from the programmer, yet sometimes the PIC will fail to program once but work without anything moving it or the adaptor assembly - it doesn't seem to be a mechanical contact problem. This happens with both PIC16 adaptors that we have (one's artwork says C 3204 below the ZIF18 socket, the other says C 0755).
The same erratic behaviour happens with other types of PIC (12F675 in adaptor, 16F84A). Should it make any difference, the programmer had its battery flat up to a few days ago when it was plugged into the charger with the reset button held down, and has been attached to the charger ever since.
This programmer has, in the past, been used to program batches of 40 PICs at a time but these problems still arose.
Theo Markettos
Sometimes it works. Other times it fails to verify, claiming all ones (3FFF), on a PIC that subsequently programs and works fine. Other strange effects are:
(these demonstrated with firmware 2.43, though the same happens with 2.99)
Do ERASE then TEST and then sometimes comes up with CODE PROTECT ON
If I try to burn, doing the following in sequence:
LOAD then EDIT shows the PIC contains all zeroes.
TEST says CODE PROTECT ON
ERASE proceeds without error.
TEST says CODE PROTECT ON
Download an image with RECEIVE INTEL, EDIT shows the hex file has come down fine.
BURN proceeds as normal, then verify fails:
0000 RAM=2844 ROM=3FFF
and so on for every location
LOAD then EDIT shows the PIC apparently still contains all zeroes and TEST shows CODE PROTECT still ON.
Sometimes it can be made to work by changing the device type and then changing it back again and reconfiguring the PIC, but this is by no means guaranteed. It still shows the same behaviour even if the PIC is completely removed from the programmer, yet sometimes the PIC will fail to program once but work without anything moving it or the adaptor assembly - it doesn't seem to be a mechanical contact problem. This happens with both PIC16 adaptors that we have (one's artwork says C 3204 below the ZIF18 socket, the other says C 0755).
The same erratic behaviour happens with other types of PIC (12F675 in adaptor, 16F84A). Should it make any difference, the programmer had its battery flat up to a few days ago when it was plugged into the charger with the reset button held down, and has been attached to the charger ever since.
This programmer has, in the past, been used to program batches of 40 PICs at a time but these problems still arose.
Theo Markettos