×
INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

EEPROM being destroyed during processor programming

EEPROM being destroyed during processor programming

EEPROM being destroyed during processor programming

(OP)
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

RE: EEPROM being destroyed during processor programming

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

RE: EEPROM being destroyed during processor programming

(OP)
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

RE: EEPROM being destroyed during processor programming

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

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

RE: EEPROM being destroyed during processor programming

"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.  

RE: EEPROM being destroyed during processor programming

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: Eng-Tips.com Forum Policies

RE: EEPROM being destroyed during processor programming

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

RE: EEPROM being destroyed during processor programming

Quote (IRstuff):

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

RE: EEPROM being destroyed during processor programming

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 winky smile

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

RE: EEPROM being destroyed during processor programming

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

RE: EEPROM being destroyed during processor programming

Yeah, my bad, I'm overly pedantic sometimes winky smile

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: Eng-Tips.com Forum Policies

RE: EEPROM being destroyed during processor programming

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

RE: EEPROM being destroyed during processor programming

(OP)
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

 

RE: EEPROM being destroyed during processor programming

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
 

RE: EEPROM being destroyed during processor programming

(OP)
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.

RE: EEPROM being destroyed during processor programming

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

Dan - Owner
http://www.Hi-TecDesigns.com

RE: EEPROM being destroyed during processor programming

(OP)
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.

RE: EEPROM being destroyed during processor programming

Quote (rogerjef):

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

RE: EEPROM being destroyed during processor programming

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: Eng-Tips.com Forum Policies

RE: EEPROM being destroyed during processor programming

(OP)
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

RE: EEPROM being destroyed during processor programming

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

 

RE: EEPROM being destroyed during processor programming

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.

 

RE: EEPROM being destroyed during processor programming

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

RE: EEPROM being destroyed during processor programming

(OP)
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

 

RE: EEPROM being destroyed during processor programming

Quote (rogerjef):

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

Quote (rogerjef):

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

RE: EEPROM being destroyed during processor programming

(OP)
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.

RE: EEPROM being destroyed during processor programming

(OP)
Yes.

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

Nothing showed.

RE: EEPROM being destroyed during processor programming

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

RE: EEPROM being destroyed during processor programming

(OP)
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.

  

RE: EEPROM being destroyed during processor programming

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: Eng-Tips.com Forum Policies

RE: EEPROM being destroyed during processor programming

(OP)
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

RE: EEPROM being destroyed during processor programming

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: Eng-Tips.com Forum Policies

RE: EEPROM being destroyed during processor programming

I had to look up "tango-uniform". smile 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

RE: EEPROM being destroyed during processor programming

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: Eng-Tips.com Forum Policies

RE: EEPROM being destroyed during processor programming

(OP)
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.
 

RE: EEPROM being destroyed during processor programming

(OP)
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  

RE: EEPROM being destroyed during processor programming

That doesn't seem like enough resistance to cause issues.  

How long is your cable?  You can build up a lot of voltage on an unterminated cables as it swings through the air.  Once you plug it in that voltage surges through your circuit.   

RE: EEPROM being destroyed during processor programming

(OP)
The RS232 serial lead, used for powering the board during programming, is approx. 2m long, as is the lead to the Real Ice programmer. The lead from the programmer to the header is approx 400mm.

The serial lead is always plugged in first.

One interesting thing is that the SCLK pull down resistor is physically sited next to M0.

I can very vaguely see a mechanism for failure, but it is clutching at straws.

During programming there is pulsatile current flowing in the 0V return to the programmer. If that line is high(ish) resistance, and maybe with some inductance, then possibly programming current could flow down the RS232 gnd.

This may possibly cause a spikey voltage to be developed across the pull down resistor directly connected to M0, stressing and maybe killing it.

The other memories might be protected by track inductance.

As I say, straw clutching at it's maximum

RE: EEPROM being destroyed during processor programming

Blowing an input requires either a forward-biased junction running amps, or the standard reverse-biased junction running 10+ kV.

An induced EMF in the ground leads are usually less than 1 V.

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

RE: EEPROM being destroyed during processor programming

(OP)
As I said, Gents. Straw clutching at it's peak.

I guess I will now have to wait until the next occurance.

Thanks for your suggestions

Roger

RE: EEPROM being destroyed during processor programming

Do you have passive resistor pullups on the Hold and Write protect inputs?  I would also consider pullups on the chip select for that M0 chip.  Are you using 3V3 for the entire board or is there also 5V powered devices associated with the serial bus?

If M0 is the only one blowing, then the chip select is the only unique line for that chip.  I would also check the actual board layout to ensure there is nothing connected to the DNC pins of the chips etc.  Do not rely on a schematic drawing.

RE: EEPROM being destroyed during processor programming

(OP)
Pullups on chip select lines only. Pull down on SCLK.

The whole of the digital section runs from 3V3. There is +/-5V supplies for the analogy bits.

There are no DNC connections on the SOIC8 version of the M25P16.

Just M0 failing is the confusing bit.

RE: EEPROM being destroyed during processor programming


I'm not sure of the SCLK 'stuck'.  If there is hardware damage to the M25P16 clock input, then try adding a small input resistor such as 10R to the SCLK input and CE input so that you can see if the inputs are sourcing fault currents.  

Like you say, there must be some definite reason for only M0 to be affected so far.  Usually power-up transients are where damage like this are liklely to occur.   

RE: EEPROM being destroyed during processor programming

For some overkill monitor Airwaves with a spectrum analyzer.

could a long unscreened track be grabbing local RF tuned to its  length , Mobile phone / TAXI pickup  .

They stop people transmitting on  oil-rigs !  

RE: EEPROM being destroyed during processor programming

There's no way for me to know if this is your issue, but some manufacturers are notorious for having issues at "unspecified voltage" that can occur during shutdown (sometimes startup) between the time the voltage drops below minimum operating voltage but there's still enough voltage to operate.  Shutdown is usually worse since its often slower.  Low power devices are worse yet.  If this is a test setup, there's probably a nice big power supply that can run the system a long time as the voltage drifts down making things worse yet again.   You can get into weird situations where some op codes work,others don't, etc...
  
In many instances a robust reset signal is all that is required to keep the system from running, but in others it may be necessary to take even more precautions. A watchdog on the power supply should be sufficient but check with the manufacturer or test it yourself.   Failure to do so can result in some very odd behavior...The system works great until you shut it off, then intermittant issues pop up depending on where you were in the code when you start shutting down and how quickly you actually turn off.

I have seen systems with bootcode programming capability take themselves out during these transients.  We could never see how we hit the code, then the mfgr informed us that at some voltage level the branch instructions no longer operated reliably and we just blew through the bootloader and erased program memory.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members!


Resources