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

 

[MacGyverS2000]

Define "destroyed"...

Are you unable to access the data anymore, are certain cells no longer programmed to their original levels, etc.?

Dan - Owner

http://www.Hi-TecDesigns.com

 

[rogerjef]

There is certain data contained in the first few pages that is required by the code. If the data is not accessable the code hangs.

So as far as we can determine, at the moment, the first pages, at least, are un-readable

 

[IRstuff]

Sounds like your programming algorithm has issues. Have you tried to reprogram a "destroyed" EEPROM?

TTFN

FAQ731-376

 

[VEBill]

"We have monitored the voltages..."

In addition to a hundred other possibilities, if you "monitored" the voltages with a meter then you could easily miss short duration events that might be occurring during a programming cycle. Unless you used a digital oscilloscope with cleverly adjusted triggers, the monitoring exercise may not have proven anything.

 

[IRstuff]

And note that just because you successfully did the operation 50 times, doesn't mean you don't have a problem. The Space Shuttle Challenger died after 24 "successful" Shuttle flights.

TTFN

FAQ731-376

 

[geekEE]

BTW, that part is a serial flash, not an EEPROM.

Does your dsPIC application only read, or does it do some erasing and writing? If it's only the first few pages that are bad and the rest of the device is ok, then maybe they are getting worn out from too many erase/write cycles.

Glenn

 

[IRstuff]

Flash is one form of EEPROM

TTFN

FAQ731-376

 

[MacGyverS2000]

Flash is one form of EEPROM

In about the same way a FET is one form of transistor... true, but man, the rules to use each are vastly different.

<written by someone currently fighting with dual small/large-page NAND Flash algorithms for a bootloader> Oh how I miss the days of individually addressable element EEPROMS...

Dan - Owner

http://www.Hi-TecDesigns.com

 

[IRstuff]

OK, but I'm a technologist. At the transistor level, the memory elements are essentially identical. The difference is in the readout and physical arrangement of the memory elements on the chip. You can make an "EEPROM" just as inaccessible as a serial device. That's the fault of the EE who designed the chip, not the technology ;-)

TTFN

FAQ731-376

 

[geekEE]

IRstuff, I know that semantically you are correct, but as far as I know, most memory manufacturers put serial flash and serial EEPROM in separate categories. I guess common usage has split them that way.

Anyway, the point of my making a distinction was because serial flash is block-eraseable and often survives fewer write/erase cycles than serial EEPROM.

Glenn

 

[IRstuff]

Yeah, my bad, I'm overly pedantic sometimes ;-)

While EEPROM technology has poorer W/E endurance than EPROM, it's still pretty good, and should be nowhere near only 50 cycles. But, it's possible that the OP has purchased some bad parts. However, it's usually unlikely that all bits in a block would all be identically failed within a single cycle, since there's still some variability within the process, even at that small a scale.

That, in of itself, would suggest that there's some sort of intermittant F/W or S/W bug, that either accidentally causes the block to be munged, or causes the programming cycle to be shortened or aborted altogether.

TTFN

FAQ731-376

 

[MacGyverS2000]

NAND should be good for 10k cycles per block... at a minimum it should be good for 1k+ cycles. EEPROM has much longer lasting power. If entire chunks of data are missing/corrupted, you have either an issue with the electrical side of things (Vpp power line is noisy, Vss is weak, etc.), or your write algorithm is either buggy or being fired without your knowledge.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[rogerjef]

The monitoring of the M25P16 was done using a digital scope, and refered to a known good ground. The maximum -ve swing on any pin was 250mV. The whole processory bit is running from 3V3.During reloading code none of the M25 pins exceeded 3V6.

The operating code is stored exclusively in the dsPIC. The M25P16 is used only as a data store.

There are 4 M25s in the array.

Particular operating parameters are stored in the first few pages of the M25, (M0).

The loading of the operating parameters is done through a serial link when the code is running normally. These pages are occationally written to updating the parameters during any particular run.

It is only after a code reload that the M25 becomes "unobtainable". I am having some code written to determine if it is the first few pages of the first block, or the whole of the first block, or if it is the whole 32 blocks.

Replacing the M25P16 deemed M0 cures the problem

 

[zappedagain]

After reading your original post again, I see that you are in a test fixture. Are you sure you aren't seeing ESD issues? The machine-model for ESD is much more stringent than the human-body model.

Are you sure your clock rate is compatible between the two devices? I've seen latch-up type issues on some devices when they get clocked too fast and destroy themselves (this was a motor driver, so it may not be applicable but it did come to mind).

John D

 

[rogerjef]

Thanks for the thought.

The test rig comprises of a production chassis, (of what is essentially an inertial platform), and a stand that just varies the inclination and azimuth of the chassis.

The processor, during programming, is powered from a lapdog which also drives the Microchip Real Ice programmer.

It is difficult to see how ESD could be a problem.

I was wondering if there might be some sort of bleed through from the 13V programming voltage, (applied to the dsPIC), and the SPI port. I have not observed any spikes during programming.

 

[MacGyverS2000]

Any chance you're using Delrin washers or joint mounts in the moving assembly?

Dan - Owner

http://www.Hi-TecDesigns.com

 

[rogerjef]

Not that easy.

The aluminium chassis is approx 950mm long by 50mm dia. There is a fairly substantial BLDC motor on one end. The chassis sits on an alloy frame which is approx 1400mm long.

The whole of the test rig, that the chassis is attached to, is non-magnetic.

It is not possible to connect either the serial, (RS232), lead, (for power), or the programmer to the processor board without touching the chassis for orientation. Any personal static charge would be disappated in the mass of the chassis/test rig.

There is no plastic involved in the design.

 

[MacGyverS2000]

Any personal static charge would be disappated in the mass of the chassis/test rig.

Are you saying the entire rig is ungrounded? Static charge does not dissipate because it hits something with a lot of mass (unless that mass is the Earth). If the moving chassis itself is what's generating the charge (and it's not grounded), you will have issues with charge build-up.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[IRstuff]

I still don't seem to have gotten any indication of what your M0 page actually looks like after "failure." Are the bits zero, or one, or what? Does the part still function otherwise? You use "inaccessible" but do not define what that really means.

Are the other memory blocks affected in any way? Can you fill the unused memory blocks with a pattern so that you can do more diagnose on the next failure?

TTFN

FAQ731-376