Non working PIC16F877A's -> non CCS issue

[Gtek]

hi all,

I know this hasn't anything to do with CCS, but i have ordered a bulk pic16F877a's from microchip direct sales in which at least 3 where faulty.
They were shipped from singapore.
These are, as it seems, eeprom problems. Programming errors.
This is a bulk of 20 pic's, which means that more then 10% is faulty.
Does someone has the same issue with pic controllers?

They are 100% genuine.

Regards,

Evert

[PCM programmer]

What programmer are you using ?

[JamesW]

There was originally a programmer issue, where older picstart plus programmers didn't recognise the A suffixed parts.

The new programmable add on has solved this.

James

[d00dajo]

We have experienced similar problems with our latest delivery, though these where 18f4680 controllers. The internal eeprom readout- or writelogic is not functioning properly. MChip is investigating what causes the eeprom failures in production. I think we estimated 2-3% faulty circuits in the delivery.

Anyone else having problems specifically with the internal eeprom faulty on delivery? (Regardless of which specific model). If so, send me a mail. If we are many who experience unexpectedly high fault rates, something bad could be going on in the production plants.

//DJ.

[PCM programmer]

You can get more information about problems by
searching the erratas for other PICs. To do this,
go to the Advanced Search page on the Microchip site:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2043
Then set the document type to: Errata
In the box for Exact Phrase, type in: data eeprom
It comes back with 44 results. (It only shows 5 results
initially. You have to click the More Errata button to
see the rest of them).

Start looking through all the 18F results.
Several of them talk about Data EEPROM corruption
during reading. CCS may already have handled
this bug by doing the recommended work-around.
But, you should look at the .LST file for your PIC
and make sure that they've done it.

Other PICs, such as this one have got some kind of wacky
write bug with the Data EEPROM:
PIC18F1220/1320 Rev. B4 Silicon/Data Sheet Errata
The work-around involves the LVD or BOR modules.

If you want to investigate your problem, you should assume
the possibility that your PIC has got one or more of these
existing Data EEPROM problems, because so many other
PICs have them.

[Eugeneo]

I've been trouble shooting batch of 16F877A chips. Seems like the program counter just stops in it's tracks.

Prior to this i've used a few hundred 16F877 without a snag for this particular project. With the A part, it seems like I can't get a single unit to pass any tests. I am not using the brownout detect and I am not doing any eeprom opperations.

Anyways, it's not worth it to spend anymore time on this so anybody want 50 bargin price 16F877A.

[asmallri]

[Mark]

Are you programming the parts as 16F877's or as 16F877A's?
What programmer are you using? Maybe it is the cause.

[Eugeneo]

I've compiled with the 877A specs.

The specs. tell me it's not necessary to turn of the comparitor (added in the A part) since it is off on powerup.

I am using a MachX programmer

I've found the problem. For some reason when I output 7 or 8 pins high on port B simultaniously, Some of port d pins go high for an almost undetectable time (a few nano seconds). I can't even trigger it on my scope, but since I have some really high speed logic chips in port d, they latch when the are not supposed to. I used the directive #fast_IO so they can be only be output and to ensure nothing is happening in the transition period defining the tris register.

I'm guessing the 877 part has a higher capacitance per pin compared to the 877A due to silicon size and structure. I put some 22 pf cap "terminators" on the data lines and fixed the problem.

One thing I did find odd. I put 330 ohm pull downs at the end of the data lines and didn't even fix the problem. So it is possible that the chip is actually sending the high pulse for a few nano seconds out port d when I send a 7 or 8 lines high? (I've obviously checked for meg-ohm continuity between port b and d pins and signal integ.)

Anybody have any thoughts on this?

[treitmey]

perhaps your 'fast' chips are seeing some noise. and NOT the output from port d. Try a simple pull-down on the naughty pins.