EEPROM being destroyed during processor programming

[rogerjef]

Hi

We have a very occational problem that results in a M25P16 EEPROM being destroyed during the programming of the associated dsPIC30F6015 microcontroller.

We have monitored the voltages around the EEPROM and all are within the normal operating voltage limits during the programming.

The board in question is one being used for development, and has had the EEPROM changed twice in the last 4 months. The board, installed in a test rig, has been re-programmed probably about 50 times without problems.

Has anyone else experienced this type of failure??

Thanks

 

[rogerjef]

No the rig is earthed, the point I was making was that any personal charge would be shared with the capacitance of the rig, which is considerable.

There was one instance of failure when a board was on an antistatic mat on a bench. All static precautions were observed. Once again the processor was being re-programmed

 

[rogerjef]

IRstuff, It was not possible to test the chip, as it seems that the SCLK was stuck

 

[VEBill]

The data sheet for the M25P16 mentions some interesting tidbits that might be worth double-checking:

"There is an exposed central pad on the underside of the VFQFPN package. This is pulled, internally, to VSS, and must not be allowed to be connected to any other voltage or signal line on the PCB." (not likely an issue)

"Resistors R (represented in Figure 4) ensure that the M25P16 is not selected if the Bus Master leaves the S line in the high impedance state." (curious...)

"Deep Power-down (DP) ...can also be used as a software protection mechanism, as in this mode, the device ignores all Write, Program and Erase instructions." (useful feature to implement?)


Sometimes these sorts of problems are eventually resolved using obscure information that would never in a million years be provided. In other words, things we can't see from here.

 

[geekEE]

During programming, how is the system powered and grounded? You have the device being programmed, some sort of programming equipment, and a computer I assume.

Glenn

 

[IRstuff]

"SCLK was stuck"

Stuck how? C is an input.

TTFN

FAQ731-376

 

[rogerjef]

During programming, the board is powered via a serial link, RS232, and programmed by the use of a Microchip Real Ice programmer. Both are plugged into a lapdog.

I know it is an input, but SCLK has been seen stuck high or low.

One of the first things that the code does, after setting ports etc, is to read the first pages of M0, which contains operating parameters. The memory array contains only data, not operating code.

It is at this point that the code hangs. The data is not read, and the code waits until it is read. If the page contents were corrupted, by having cells "damaged", data would still be read, and the code would continue to run.

If SCLK is stuck in one state the processor cannot clock the data, so keeps trying.

I suspect that SCLK is damaged. Replacement of the M25 is the only cure. The M25 is the SO8 part.

Interestingly, there are 4 M25s in the array, but only M0 is affected.

The board has had the serial lead plugged in many 100s of times without causing problems. It is only the act of programming that has "killed" the M25

 

[MacGyverS2000]

IRstuff, It was not possible to test the chip, as it seems that the SCLK was stuck

I know it is an input, but SCLK has been seen stuck high or low.

You don't see a conflict with those statements? If C (SCLK) is an input and the line is being held low or high, you've either blown the line internal to the EEPROM (i.e., electrical short due to overcurrent / overvoltage), or your processor is not releasing the line (i.e., a programming error or the processor is getting locked up due to voltage transients).

Seems like there's quite a bit of useful info there to help track down the problem.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[rogerjef]

Yes, I agree that the input is blown.

I don't understand how, or why.

It only happens during a programming operation. The board has been programmed probably 70-80 times, and I have had to change the M25 twice, and with several months between changes.

I removed the board from the test rig yesterday and have been playing with it on the bench. I programmed the board some 50 times today, no failure occured.

Interestingly, M0, (the only chip to be damaged), is furthest away from the processor and at the end of the SPI chain. M3, the closest to the processor, does not fail.

There is also an AD7656 ADC attached to the SPI bus, but this is sited the other side of the processor. This device is also unaffected.

 

[IRstuff]

Is C blown on all the dead chips? If so, what's the rationale for chasing W/E endurance?

TTFN

FAQ731-376

 

[rogerjef]

Yes.

I assumed that something was happening on the SCLK line, and I was monitoring that line as I was programming.

Nothing showed.

 

[IRstuff]

Have you attempted to test the bad chips outside of the test station?

TTFN

FAQ731-376

 

[MacGyverS2000]

How far away from the PIC is M0?

I'm with IR, you seems to be chasing the wrong dog's tail, and the info coming to light recently is starting to scream electrical issue... input lines don't fail on multiple chips without a serious upset event causing it. If it is static buildup, you'll have a tough time tracking it down as any attempt to monitor the line in question means a connection to ground through the test equipment (even if it's a relatively high-impedance).

Dan - Owner

http://www.Hi-TecDesigns.com

 

[rogerjef]

About 45mm.

I agree that it is an electrical issue of significant proportion. But, why only when programming, and possibly only after 40(ish) code loads.

Why only M0, when there are 3 other devices connected to the SPI?

One of my posts wondered if there was some sort of bleed through when the processor I/O was put into HiZ state during programming, but this would not explain M0 only.

On the very few occasions that there has been a failure there has been no difference in the proceedures adopted for programming.

The serial lead has been connected 100s of times without problem. It, surely, must be programmer/programming related.

 

[IRstuff]

Agreed that it's a frustrating type of problem.

Again, have you independently verified that the parts are tango-uniform?

Do you have sufficient records to identify:
> operator(s) for each programming run
> time of day of each run
> etc.

TTFN

FAQ731-376

 

[rogerjef]

I am not sure if the parts were tango-uniform, but I am sure that they were bravo-uniform-golf-golf-echo-romeo-echo-delta.

I am the only person programming the development kit, programming could be several times in a day, and then not for weeks. Typical of any design development.

The time of day could be anything between 08.00 and 17.15H.

There is nothing identifiably different with the programming proceedures/methods

 

[IRstuff]

Are the parts still around? They could be sent out for destructive evaluation.

It seems, currently, that the most likely immediate COD is some sort of destructive signal on the clock pin. However, an odd observation is the stuck high on the clock pin. The clock driver should be able to overcome most normal loads. To get that pin stuck high would imply essentially a short to Vcc.

If so, that's relatively easy to test, even on a loose part, since you only need Vcc, Vss, and the clock pin. If you have to, you could get someone to solder some thin wires to those 3 pins. Hook up Vcc and Vss to a power supply, and set your DMM to current mode and connect it between clock and Vss. If you get a massive, i.e., >>100 uA, then that confirms that the input is seriously zapped.

If so, then it's definitely a handling or circuit problem. A circuit problem would require you to monitor the pin with an oscilloscope capable of triggering on a large voltage threshold, say, 5V, and you'll simply have to keep trying to blow up a part on the programmer and see if you can get a trigger event.

TTFN

FAQ731-376

 

[geekEE]

I had to look up "tango-uniform". I hadn't heard that before.

Is SCLK shared by all the serial flash devices? Also, did you really see some that were stuck high and some that were stuck low? Or do you just know that they were stuck, but didn't know which way?

Are there any other pins on the flash that are damaged?

Glenn

 

[IRstuff]

The only way you'd be able to tell if other pins are damaged when the clock pin is damaged is to use the approach I described for measuring the input Low short-circuit current on the other 4 pins. That would, of course, provide some more information.

TTFN

FAQ731-376

 

[rogerjef]

SCLK is shared by the four M25s and an ADC.

Unfortunately parts removed were dumped, so no postmortem.

We have tried repeatedly programming the processor, some 50 times, whilst monitoring the SCLK line with a digital scope set to trigger at 4V. Nothing failed.

A number of boards have been pulled for the development process from the boards destined for field testing.

There were early failures over a period of several months. These failures manifested themselves as loss of communication. There were two failures. The processors were suspect, (as the failures occurred after programming), and changed. The boards still failed to work. These boards were binned, as it was deemed not worth chasing the problem.

When the problem next occurred more time was spent trying to resolve the issue. The problem was traced to the inability to read M0, causing the code to hang.

M0 was changed and the board then worked, and has been working for some 6 months.

A further board was taken into the development process. In the last 4-5months it has had M0 changed twice. In the latest instance the SCLK pin was definately low. It was suggested to me that on the previous occasion SCLK was high. This I cannot be sure of.

So, three definate M0 failures, and two highly likely.

 

[rogerjef]

Hi Guys

May, repeat, may have found problem.

The 0v return on the programmer/board lead was intermittant at the programmer end.

Resistance varying from 5 to 76R. New cable 0,5R.

Only time will tell.

Thanks for all you help

Roger