How do you know EEPROM chips are good

Thread Starter

SamEricson

Joined Apr 25, 2015
196
You read the original EEPROM several times to see if you get different output files
Ok so read the EEPROM several times and SAVE the file multiple times just in case right?

Then you compare the saved files against each other in the universal programmer software?

Also using different universal programmers to test the same EEPROM chips because they read, write, and check sum differently right? each universal programmer has different debugging and flagging errors?
 

dl324

Joined Mar 30, 2015
8,918
Ok so read the EEPROM several times and SAVE the file multiple times just in case right?
Read the EEPROM at low, nominal, and high VCC. If you get the same data at all three voltages, it's either correct or the data is too far gone to recover.
Then you compare the saved files against each other in the universal programmer software?
Data read at low VCC is more likely to be correct if charge loss is the problem. Load that into the programmer and compare against the EEPROM at high VCC.
Also using different universal programmers to test the same EEPROM chips because they read, write, and check sum differently right? each universal programmer has different debugging and flagging errors?
Programmers should may be able to calculate checksums using several different algorithms, you need to know which applies to your data (if at all), and what the expected checksum is.
 

dl324

Joined Mar 30, 2015
8,918
Depends if you mean an existing program is OK or if they are OK after full erasure?
A full erasure followed by a validity check is a simple procedure for most eprom programmers.
Most EPROM programmers can't erase EPROMs.
Many common problems occur because the erasure window has not been covered, I have seen eproms affected where the enclosure door has been left open and exposed to sunlight.
OP is talking about EEPROMs, not EPROMs. EEPROMs have no quartz window and can only be erased electrically.
 

Thread Starter

SamEricson

Joined Apr 25, 2015
196
Programmers should may be able to calculate checksums using several different algorithms, you need to know which applies to your data (if at all), and what the expected checksum is.
That is why it's best to use different universal programmers to test the same EEPROM chips because they read, write, and check sum differently right? each universal programmer has different debugging and flagging errors?

Each Universal Programmer calculates the checksum differently because each Universal Programmer has a different algorithms for the check sum, debugging errors and flagging errors?

A Bad EEPROM chip might pass on a couple of universal programmers, but will fail on other universal programmers why is that?
 

dl324

Joined Mar 30, 2015
8,918
That is why it's best to use different universal programmers to test the same EEPROM chips because they read, write, and check sum differently right? each universal programmer has different debugging and flagging errors?
No. They should all read, write, and generate checksums in an equivalent manner.
Each Universal Programmer calculates the checksum differently because each Universal Programmer has a different algorithms for the check sum, debugging errors and flagging errors?
Checksums for each algorithm need to be generated in exactly the same way.
A Bad EEPROM chip might pass on a couple of universal programmers, but will fail on other universal programmers why is that?
Ideally, all programmers would detect the same failures. But all programmers aren't created equal.

Do as I suggested a couple times now. Read the data (on the same programmer) at low, nominal, and high VCC. Start by comparing the data read at low VCC with the device operating at high VCC. This configuration should detect charge loss (margin) issues. If data from the two voltages compares the same, charge loss may not be the problem; or the device may have lost too much charge to be salvageable and you'll need to locate a source for the original programming.

If the device itself has gone bad (decode logic, etc), you'll need to locate a source for the original programming.

Is the device using the EEPROMs failing some sort of self test?
 

Thread Starter

SamEricson

Joined Apr 25, 2015
196
But all programmers aren't created equal.
What do you mean by created equal?

you'll need to locate a source for the original programming.
That will be a problem. I will have to use another circuit board from another unit that has the same EEPROM chips to read the files from.

What kind of code is on EEPROM chips? C++, assembly language, basic, fortran?

what is on EEPROM chips i never really knew what is on EEPROM chips?
 

dl324

Joined Mar 30, 2015
8,918
That will be a problem. I will have to use another circuit board from another unit that has the same EEPROM chips to read the files from.
If you have access to another board, make sure the EEPROMs are the same revision level?
What kind of code is on EEPROM chips? C++, assembly language, basic, fortran?
Can't even make an educated guess without more information.
what is on EEPROM chips i never really knew what is on EEPROM chips?
Ditto...
 

Thread Starter

SamEricson

Joined Apr 25, 2015
196
Programmers should may be able to calculate checksums using several different algorithms, you need to know which applies to your data (if at all), and what the expected checksum is.
The Universal programmer just sends an error or flags if there is a checksum error. Maybe I'm doing something wrong?

How would I know which checksum algorithm applies to the date?
 

Thread Starter

SamEricson

Joined Apr 25, 2015
196
What programming languages do you think are on EEPROM chips in general? from circuit boards in the 80's and 90's

If you have access to another board, make sure the EEPROMs are the same revision level?
Yes true I have noticed that
 

Thread Starter

SamEricson

Joined Apr 25, 2015
196
What Bad EEPROM chips I have come across in the past of my experience was they pass good on the universal programmer, but after a few months the circuit boards will come back as RMA returns and i will erase and reprogram the EEPROM chips.

This is some kind of latency failure. I would get these latency failures using EPROM chips more often because of the UV light. I don't think EPROM chips liked to be erased and re-programmed over or over they must look something in the memory cells and they get damaged. Also When I use the UV light on EPROM chips i only set it to 15mins max. is that enough time? I use EPROM labels to cover up the window. After a few months the files on the EPROM chip will be corrupted.
 

takao21203

Joined Apr 28, 2012
3,682
since wwhen EEPROM has a read lock? How could you actually access it? with a password?

Most are I2C but theres also microwire and SPI and a few other protocols I dare to mention here even.

You see why troubleshooting PCBs is a dying profession...

mostly the data is corrupt but the chip as such isnt defective + they only cost a steal.
 

djsfantasi

Joined Apr 11, 2010
5,601
A checksum is calculated when creating a file/EEPROM and is stored within the file/EEPROM. Later when the file/EEPROM is read, the checksum is recalculated. It must match the value pre-stored. If not, it's assumed there's a problem with the data.

Implicit in this scheme is that the initial and subsequent calculations must be done in an identical manner.

What I can't help you with, is how the checksum function is defined for various devices. There are different standards based on manufacturer or file format. Programmers can write a variety of manufacturers and file formats through their internal software.

Here is one reference I found during my fact checking.
 

dl324

Joined Mar 30, 2015
8,918
The Universal programmer just sends an error or flags if there is a checksum error. Maybe I'm doing something wrong?

How would I know which checksum algorithm applies to the date?
Not all devices have a checksum. The ones that do should indicate how it was calculated.
 

dl324

Joined Mar 30, 2015
8,918
What programming languages do you think are on EEPROM chips in general? from circuit boards in the 80's and 90's
They usually contain compiled code and/or data. It's unusual for them to contain source code because it would be too easy to steal. In my car, it just contains data for the ECU.
 

dl324

Joined Mar 30, 2015
8,918
since wwhen EEPROM has a read lock? How could you actually access it? with a password?
I agree. Unless the EEPROM has an embedded processor, you can't restrict read access. I've heard of some programmable devices that wouldn't let you read all of the addresses sequentially. I saw preliminary data on an Intel EPROM that had built-in authentication. Don't know if it ever became a product. I knew one of the engineers who came up with the idea.
mostly the data is corrupt but the chip as such isnt defective + they only cost a steal.
Agree. Only the memory array has limited write/erase cycles. The rest of the circuitry has the same reliability as typical NMOS/CMOS devices. Basically unlimited read.
 

dl324

Joined Mar 30, 2015
8,918
A checksum is calculated when creating a file/EEPROM and is stored within the file/EEPROM. Later when the file/EEPROM is read, the checksum is recalculated. It must match the value pre-stored. If not, it's assumed there's a problem with the data.
Checksums don't need to be stored in the memory device because it needs to be calculated on all of the data in the device and the checksum value would change the checksum... It's simpler to keep the checksum separate. Similar to the way MD5 is done on files in Unix. You generate a checksum on the file of interest and distribute the checksum with the file; as a separate file.
 

dl324

Joined Mar 30, 2015
8,918
What Bad EEPROM chips I have come across in the past of my experience was they pass good on the universal programmer, but after a few months the circuit boards will come back as RMA returns and i will erase and reprogram the EEPROM chips.
Is the programmer programming them correctly? There could be margin problems.
This is some kind of latency failure. I would get these latency failures using EPROM chips more often because of the UV light. I don't think EPROM chips liked to be erased and re-programmed over or over they must look something in the memory cells and they get damaged.
EPROMs are spec'ed to be erased/programmed dozens of times because erase/program cause damage that eventually causes device failure.
Also When I use the UV light on EPROM chips i only set it to 15mins max. is that enough time? I use EPROM labels to cover up the window. After a few months the files on the EPROM chip will be corrupted.
Are you talking about EEPROMs or EPROMs; they're different and the terms can't be used interchangeably.

Regarding erase, you erase them until they're erased. There are several variables that affect UV dosage received by the EPROM. Are you blank testing your EPROMs at 4.2V.

Are you following the correct programming procedure? Are you verifying program and erase margin? I know that some "professional" programmers don't do EPROMs correctly. You can compensate for deficiencies in your programmer by knowing what you're doing.
 

Thread Starter

SamEricson

Joined Apr 25, 2015
196
Not all devices have a checksum. The ones that do should indicate how it was calculated.
How do you know which EEPROM chips have a checksum and which don't have a checksum? the datasheets of EEPROM don't tell this information

You generate a checksum on the file of interest and distribute the checksum with the file; as a separate file.
1.) I READ the file of the EEPROM using the universal programmers software
2.) Then I SAVE the file in the universal programmers software
3.) Then I generate a checksum on the SAVED file? not from the read file right?

limited write/erase cycles.
Yes I have found problems of latency failures from using the same eeprom chips or eprom chips of erasing and writing them over and over. The write/erase cycles damage the cells in the eeprom and eprom chips it seems.
 

Thread Starter

SamEricson

Joined Apr 25, 2015
196
Are you blank testing your EPROMs at 4.2V.
I have never done a blank testing. so what do you mean?

I put the EPROM chips in a UV light eraser and set the timer to the datasheets of the EPROM chip which is about 15mins to not damage the cells. is this how you erase EPROM chips?

Are you verifying program and erase margin?
Maybe I'm doing something wrong about the margins. I'm not really sure how to set up the margins

The universal programmer software just has a button for reading, writing, erasing. I don't go into the settings and change anything or change the margins.

How Should I set it up?

Are you talking about EEPROMs or EPROMs
Yes I know the difference, I was talking about EEPROMs at first about the read, write, checksum

The EPROM chips I have latency failure problems. I think the UV light eraser is the problem and the write/erase cycling is the problem of the latency failures
 
Top