deciphering EPROM data

[tmg]

So I have a EPROM out of an RF power detector that i am trying to edit the data on. I have the a printout of the end result of what the data on the EPROM produces and i have the binary at all the addresses of the EPROM (most on which are empty). But i can't figure out how to convert the binary into anything sensible. Any ideas?

Detailed Info:
EPROM PN: CY7C291A
Datasheet: http://components.arrow.com/part/dataview/129890S1042298N5453

Data derived from EPROM:(I got these by feeding in each address into the address bus and reading the output with an arduino mega)

Detector Serial Number = 42
Det Type is 750 - 18.5GHz, Type N
Date of Calibration is 10Aug5
Calibration Location is Factory
Diode Resistance 'R0+' = 3000 OHMS
Diode Resistance 'R0-' = 4200 OHMS
Low Freq Det Response corr = 0.00dB
Table Start frequency = 0.50GHz
Table Stop Frequency = 18.5GHz
Table Frequency increment = 0.500GHz
Corr Table resolution = 0.01000dB
1   Freq=   0.50000   GHz      -0.03000
2   Freq=   1.00000   GHz      0.00000
3   Freq=   1.50000   GHz      0.00000
4   Freq=   2.00000   GHz      0.00000
5   Freq=   2.50000   GHz      0.00000
6   Freq=   3.00000   GHz      -0.01000
7   Freq=   3.50000   GHz      -0.01000
8   Freq=   4.00000   GHz      -0.02000
9   Freq=   4.50000   GHz      -0.02000
10   Freq=   5.00000   GHz      -0.03000
11   Freq=   5.50000   GHz      -0.04000
12   Freq=   6.00000   GHz      -0.05000
13   Freq=   6.50000   GHz      -0.07000
14   Freq=   7.00000   GHz      -0.08000
15   Freq=   7.50000   GHz      -0.08000
16   Freq=   8.00000   GHz      -0.07000
17   Freq=   8.50000   GHz      -0.09000
18   Freq=   9.00000   GHz      -0.11000
19   Freq=   9.50000   GHz      -0.14000
20   Freq=   10.00000   GHz      -0.17000
21   Freq=   10.50000   GHz      -0.21000
22   Freq=   11.00000   GHz      -0.24000
23   Freq=   11.50000   GHz      -0.27000
24   Freq=   12.00000   GHz      -0.30000
25   Freq=   12.50000   GHz      -0.31000
26   Freq=   13.00000   GHz      -0.32000
27   Freq=   13.50000   GHz      -0.34000
28   Freq=   14.00000   GHz      -0.35000
29   Freq=   14.50000   GHz      -0.34000
30   Freq=   15.00000   GHz      -0.34000
31   Freq=   15.50000   GHz      -0.36000
32   Freq=   16.00000   GHz      -0.39000
33   Freq=   16.50000   GHz      -0.39000
34   Freq=   17.00000   GHz      -0.40000
35   Freq=   17.50000   GHz      -0.40000
36   Freq=   18.00000   GHz      -0.40000
37   Freq=   18.50000   GHz      -0.50000

EPROM Binary values

Address      Output    Dec   Hex
0   ,   00000000   0   0
1   ,   00000000   0   0
2   ,   00000000   0   0
3   ,   01011000   88   58
4   ,   00000000   0   0
5   ,   00000000   0   0
6   ,   00000000   0   0
7   ,   01110000   112   70
8   ,   00000000   0   0
9   ,   01000000   64   40
10   ,   00010000   16   10
11   ,   10100000   160   A0
12   ,   00000000   0   0
13   ,   00000000   0   0
14   ,   01011000   88   58
15   ,   00000000   0   0
16   ,   00000000   0   0
17   ,   00000000   0   0
18   ,   10100000   160   A0
19   ,   00000000   0   0
20   ,   00000000   0   0
21   ,   00010000   16   10
22   ,   00100000   32   20
23   ,   00000000   0   0
24   ,   00000000   0   0
25   ,   11100000   224   E0
26   ,   01000000   64   40
27   ,   01011000   88   58
28   ,   00000000   0   0
---In between Addresses Blank--
64   ,   00000000   0   0
65   ,   10000000   128   80
66   ,   00010000   16   10
67   ,   00010000   16   10
68   ,   00000000   0   0
69   ,   00000000   0   0
70   ,   01110000   112   70
71   ,   00000000   0   0
72   ,   11110000   240   F0
73   ,   11110000   240   F0
74   ,   00010000   16   10
75   ,   00010000   16   10
76   ,   00000000   0   0
---In between Addresses Blank--
127   ,   00000000   0   0
128   ,   11110000   240   F0
129   ,   00000000   0   0
130   ,   10110000   176   B0
131   ,   00000000   0   0
132   ,   00000000   0   0
133   ,   11110000   240   F0
134   ,   00000000   0   0
135   ,   11100000   224   E0
136   ,   00000000   0   0
137   ,   00000000   0   0
138   ,   00000000   0   0
139   ,   00000000   0   0
140   ,   10110000   176   B0
141   ,   11110000   240   F0
142   ,   00010000   16   10
143   ,   01110000   112   70
144   ,   11010000   208   D0
145   ,   01110000   112   70
146   ,   11000000   192   C0
147   ,   10100000   160   A0
148   ,   10000000   128   80
149   ,   00010000   16   10
150   ,   11010000   208   D0
151   ,   00010000   16   10
152   ,   11000000   192   C0
153   ,   00110000   48   30
154   ,   01000000   64   40
155   ,   01100000   96   60
156   ,   01010000   80   50
157   ,   10000010   130   82
158   ,   00100000   32   20
159   ,   01000000   64   40
160   ,   01010000   80   50
161   ,   11110000   240   F0
162   ,   01110000   112   70
163   ,   10110000   176   B0
164   ,   00000000   0   0
165   ,   11110000   240   F0
166   ,   10010000   144   90
167   ,   00010000   16   10
168   ,   01100000   96   60
169   ,   10000000   128   80
170   ,   00110000   48   30
171   ,   01010000   80   50
172   ,   11010000   208   D0
173   ,   00000000   0   0
174   ,   00010000   16   10
175   ,   10010000   144   90
176   ,   11100000   224   E0
177   ,   10010000   144   90
178   ,   10000000   128   80
179   ,   00000000   0   0
180   ,   00100000   32   20
181   ,   11110000   240   F0
182   ,   01110000   112   70
183   ,   01110000   112   70
184   ,   11100000   224   E0
185   ,   01100000   96   60
186   ,   01110000   112   70
187   ,   00000000   0   0
188   ,   11010000   208   D0
189   ,   01010000   80   50
190   ,   00110000   48   30
191   ,   10000000   128   80
192   ,   00000000   0   0
---In between Addresses Blank--
508   ,   00000000   0   0
509   ,   10000000   128   80
510   ,   00000000   0   0
---In between Addresses Blank--
1020   ,   00000000   0   0
1021   ,   10000000   128   80
1022   ,   00000000   0   0
1023   ,   00000000   0   0

[PA0PBZ]

I doubt that the EPROM data you posted is correct, what are the odds that bit0 and bit2 are always zero, and bit1 is 1 only once?
And how exactly did you get what you call data derived from EPROM?

[kfitch42]

I doubt that the EPROM data you posted is correct, what are the odds that bit0 and bit2 are always zero, and bit1 is 1 only once?
And how exactly did you get what you call data derived from EPROM?

And bit 3 is set only thrice.

Is the data extraction repeatable? Check for loose connections.

The best approach (once you can reliably/repeatably extract the data) would be to try mucking a bit somewhere and see what changes in that report.

[kfitch42]

The CY7C291A is a high-performance 2K-word by 8-bit CMOS PROM.

You only showed us 1K of data.

This is an EPROM, not an EEPROM. Do you have a windowed package? I think this guy can only be reprogrammed after getting UV exposed to erase.

[tmg]

And how exactly did you get what you call data derived from EPROM?

It is highly possible that i am doing this all wrong, this is my 1st adventure with an EPROM.
I dont have a proper EPROM programmer so am trying to hack one together with an arduino
i hooked up all the address lines to outputs from the microcontroller  and i  am reading the output in
I turn the enable pins on and just count up in binary recording the output.

  Do you have a windowed package?

Yes

[kfitch42]

I dont have a proper EPROM programmer so am trying to hack one together with an arduino
i hooked up all the address lines to outputs from the microcontroller  and i  am reading the output in
I turn the enable pins on and just count up in binary recording the output.

Reading the EPROM from an Arduino should be doable. Writing to it will be much tougher.
Note that you will need 12V on /CS1 to program. Also from the datasheet:

. Programming algorithms can
be obtained from any Cypress representative

I suspect you will be better off buying an actual programmer. Just check that it supports your chip. I did a quick check and I don't think the one Dave reviewed recently supports your chip.

[PA0PBZ]

At first: you can't change the values in the EPROM without erasing (with UV) and reprogramming the device, so editing the data is not that easy.

Then, you list the contents of the EPROM twice, the first table is readable text and the second one contains values. What is the difference?

Maybe it would be a bit easier to give you advice if you can tell what model of RF power detector you are working on and what you are trying to do. A picture of the PCB would help also.

[tmg]

At the moment all i want to do i read it and figure out how it is encoded. Basically i want to be fairly certain that i will be able to know what to write to the chip should i get a proper programmer.

Then, you list the contents of the EPROM twice, the first table is readable text and the second one contains values. What is the difference?

The 1st data the text is what i read off the machine's display when it is reading the rom.  the 2nd, all binary is what i can read off the chip

i am trying to figure out what addresses on the chip relate to what data.

Ideally i would find an eeprom that i could replace this on with but i haven't started that search yet b/c it is pointless if i dont know what the data means

[PA0PBZ]

Something doesn't make sense (yet).
If the calibration data is in the EPROM there is no easy way to recalibrate the device.
What else is in the RF detector, is there also an EEPROM maybe?

[free_electron]

you don't recalibrate these things. the only time recalibration is need is if the thermistors in the bolometer have been altered. as this is an undoable thing unless you have wirebonders this calibration is useless.
This is factory work. They measure the device , calculate compensation values for the meter and store this in the eeprom. There may not even be a direct relation between the printed table on the unit and what is stored in the rom.

why do you want to play with this ?

[PA0PBZ]

you don't recalibrate these things. the only time recalibration is need is if the thermistors in the bolometer have been altered. as this is an undoable thing unless you have wirebonders this calibration is useless.
This is factory work. They measure the device , calculate compensation values for the meter and store this in the eeprom. There may not even be a direct relation between the printed table on the unit and what is stored in the rom.

I agree, but since it lists both the calibration date and says "factory calibration" it makes me wonder. Why are you so sure it is bolometer based?

why do you want to play with this ?

Yes, that is what I tried to ask.

[free_electron]

you don't recalibrate these things. the only time recalibration is need is if the thermistors in the bolometer have been altered. as this is an undoable thing unless you have wirebonders this calibration is useless.
This is factory work. They measure the device , calculate compensation values for the meter and store this in the eeprom. There may not even be a direct relation between the printed table on the unit and what is stored in the rom.

I agree, but since it lists both the calibration date and says "factory calibration" it makes me wonder. Why are you so sure it is bolometer based?

why do you want to play with this ?

Yes, that is what I tried to ask.

cause most of the agilents are bolometer based.... his list shows two diode resistances ...

maybe tha rom sits in a socket and is swappable by the callabs. they would then have a piece of software that alters the infor , writes a new rom , tech swaps roms and puts cover back on.
or , if the probe is being repaired in a service center thise guys would write new prom and it would not say factory but 'refurbished' . that way you know it has been reworked.

educated speculation on my part ...

[bilko]

Once you have managed to retrieve the data from the EPROM you can copy it to a NVRAM. I'm sure that you will find a chip that has the same address and data lines. Just hook up a battery backup supply and you can switch between your gear and the arduino rig, no need to Erase and reprogram EPROMS. I have done this in the past, a long time ago and it works without any problems.

[tmg]

maybe tha rom sits in a socket and is swappable by the callabs. they would then have a piece of software that alters the infor , writes a new rom , tech swaps roms and puts cover back on.
or , if the probe is being repaired in a service center thise guys would write new prom and it would not say factory but 'refurbished' . that way you know it has been reworked.

This is precisely it, but i cant get the device that programs the proms anymore. It was an extension of the power meter and you program it by typing into the meter.
So the old way the meter and extension would encode the data for you onto a new prom.

The Sensor is a gigatronics 16000 something (1693? i dont have it in front of me right now).

you don't recalibrate these things. the only time recalibration is need is if the thermistors in the bolometer have been altered.

This sensor is diode based and the mfr flyer says PROM and diode detectors are field replaceable.
http://www.gigatronics.com/uploads/document/8500A-Series-Power-Meter-Datasheet.pdf

why do you want to play with this ?

Because I have some sensors that read very close to nominal when you force the offset to be zero, by selecting a freq of 1GHz regardless of input, but when you specify the frequency and it applies the offset for that freq. the reading its sufficiently off.

Once you have managed to retrieve the data from the EPROM you can copy it to a NVRAM. I'm sure that you will find a chip that has the same address and data lines. Just hook up a battery backup supply and you can switch between your gear and the arduino rig, no need to Erase and reprogram EPROMS. I have done this in the past, a long time ago and it works without any problems.

if it is non-volatile why the need to batt. backup. which wont work for me b/c these sensors can spend alot of time unplugged.

[kfitch42]

Once you have managed to retrieve the data from the EPROM you can copy it to a NVRAM. I'm sure that you will find a chip that has the same address and data lines. Just hook up a battery backup supply and you can switch between your gear and the arduino rig, no need to Erase and reprogram EPROMS. I have done this in the past, a long time ago and it works without any problems.

if it is non-volatile why the need to batt. backup. which wont work for me b/c these sensors can spend alot of time unplugged.
[/quote]

It is somewhat common for test equipment to store cal data in SRAM with a battery backup connected to the SRAM, which can last years. Maintaining data is SRAM doesn't take much power. You can search around this forum and find numerous threads about changing batteries in benchtop multimeters.

As I understand it a 'true' NVSRAM essentially contains an internal battery, with a specified lifetime (e.g. 10 years).

I am guessing there isn't much room inside the power sensor to make a mod like adding a battery. Guess you could just duck tape it on the outside

Getting a pin compatible (NV)SRAM is probably going to be necessary, at least for figuring this guy out. The datasheet on your EPROM suggests a 35minute erase time. Trying out different tweaks to the data might be quite painful if it takes close to an hour to tweak a bit and try it out.

What speed grade is your chip? The data sheet lists 20ns, 25ns, 35ns, and 50ns variants. A quick parametric search on digikey suggests that getting 20ns or faster severely limits your options.