16F877 programming blues.

[dwarshout]

Hi all,

I recently finished building a parallel port programmer and have been playing around with a 16F877-04P. All was well at first but as time passed I started to get verification errors while programming the chip, increasing in frequency until it has now reached the stage where I can't program it successfully anymore. Browsing through this forum I've now eliminated the PC, parallel port cable, programmer software and programmer voltages.

WinPic800 reports random addresses, 0862h, 0882h, 08F2h, 0902h, 0a12h and 0a39h at fault. When I read back the contents of the chip the reported address has the correct value but of course programming did not commence beyond that address. If I program the chip completely without verification then lots of addresses have bits cleared in them. If I fill the entire code range with bit patterns such as 1555h and 2aaah then programming and verification is successful.

I've now accepted that the chip is probably faulty is some way but would very much like to know what could've caused the problem so that I can prevent a reoccurence. Known mishaps with this chip is that I once programmed it as a 16F877A and today I discovered that I wasn't using a 4 MHz crystal in its test cicuit but a 20 MHz one. Not that it was protesting about it at the time.

Can anybody throw some light on the subject?

Regards,
Peter.

 

[Nigel Goodwin]

I've never seen a PIC fail in that way?, it sounds more like a problem with the programmer or software?, or perhaps a timing problem?.

Anyway, to try and check what's wrong, try erasing your PIC, just like an EPROM when erased all the bits are 1's - so it should then all read 0x3FFF.

During programming (again, just like an EPROM!) you can only change a '1' to a '0', and NOT a '0' to a '1' (which is why it's erased before programming).

 

[dwarshout]

There isn't a problem successfully erasing this PIC. I've tried different programmer software which gave similar results and also played around with the settings they offer. I've also experimented with simple RC filters on the programmer clock and data lines to no avail.

What doesn't make sense to me is that everything worked fine initially, then the first verification error occurred and after that increased at a steady rate. I've got this sneaky suspicion that clocking this chip at 20 MHz might have had something to do with it.

Regards,
Peter.

 

[Nigel Goodwin]

I've got this sneaky suspicion that clocking this chip at 20 MHz might have had something to do with it.

There seems no reason to suppose that 4MHz and 20MHz chips are in any way different (apart from the printing on the top). I've never seen a 4MHz chip that didn't work perfectly at 20MHz, nor ever heard of one that didn't. I suspect it's purely a marketing ploy!.

 

[eblc1388]

Hi,

Check the schematic of the programmer.

Please pay particular attention to Pin 36 of 16F877 as this is the PGM/RB3 pin which must be grounded(0V) during HVP programming.

Letting it floats or connecting it to other voltage/signal will cause all sorts of verification troubles during programming.

 

[dwarshout]

Hi,

I've spent more time with this PIC today and experimented with verification turned on both during and after programming. I found that no errors occurred with writing up to address 800h. Once writing was done above 800h, verify errors occurred during writing. What is interesting is that this then also corrupted the data below 800h which was verified as correct during programming.

One thing I always try with a component that is acting weirdly is to subject it to thermal shock and see what happens. Not having any freezer spray I first put it in hot tap water and once dry, tried again. This time it verified fully while writing but still failed verification after programming. Comparing the contents showed a vast reduction in the number of errors though. Next I put it in a mug of boiled water for a while and tried again. Guess what, for the first time in about a 100 it programmed successfully. I do not claim that this fixed the PIC but it does proof to me that the chip is at fault and that I and the programmer aren't to blame. In order to satisfy my curiosity I'll send this PIC on a few trips between the freezer and the boiler though.

I do have a 1k pull-down on pin 36 of my programmer. Since I've run out of RAM on the 16F877 I'm thinking of moving on to a 18F452. I see that on the 452 PGM is on pin 38 and no mention is made in the data sheet for the requirement of a pull-down on this pin. Does this mean that I can program it without making any changes to my programmer?

Regards,
Peter.

 

[eblc1388]

I found that no errors occurred with writing up to address 800h. Once writing was done above 800h, verify errors occurred during writing.

This is very strange indeed as 0800 is the start of Page one of the 16F877 program memory address. If errors never happens on page0, then there are several possibilities. Make sure you do not have high value capacitor like 50uF or so between the Vdd pin and 0V. A 0.1uF capacitor is all one needed.

What is interesting is that this then also corrupted the data below 800h which was verified as correct during rogramming.

There is a high probability that the codes that are destined for addresses over 0800h is being written to page0 address and thus corrupted the already "verified" memory content.

All these, I'm sorry to say, points the finger to the programming software or the delay timing or construction technique of the programmer. Are you using 7406/7407 for the programmer? You should try other software like IC-Prog or WinPicProg to see whether you gets the same result.

Next I put it in a mug of boiled water for a while and tried again. Guess what, for the first time in about a 100 it programmed successfully.

High temperature does not make things better, in fact most of the time it make thing worst.

I see that on the 452 PGM is on pin 38 and no mention is made in the data sheet for the requirement of a pull-down on this pin. Does this mean that I can program it without making any changes to my programmer?

The reason for the pulldown is easy to understand. Once the PIC has been completely erased in preparation for new code input, the "1"s in the config bit would enable the LV programming mode on the PIC. If at this moment the PGM pin is floating, the PIC may enter LVP and cause error.

This has been experienced and verified by our forum modulator Jay.

 

[Jay.slovak]

The reason for the pulldown is easy to understand. Once the PIC has been completely erased in preparation for new code input, the "1"s in the config bit would enable the LV programming mode on the PIC. If at this moment the PGM pin is floating, the PIC may enter LVP and cause error.

This has been experienced and verified by our forum modulator Jay.

Yes, pretty enoying problem :?

 

[eblc1388]

Yes, pretty enoying problem :?

That's why my ICSP connector has six pins instead of five. A PGM connection that I can ground.

 

[Jay.slovak]

Well, all my Proto boards have a 20K pull-down resistor (it is big enaugh that it doesn't screw-up other parts of circuit), but my problem raised at Bread board, that I used to "save" time :?