Tektronix 2445 - bad microprocessor S68A08? - Page 1
Forum section: electronics / repair

author: stephunk
author_rank: Contributor
timestamp: April 11, 2015, 08:17:02 am
content: HelloI have bought a 2445 for a reasonable price, checked visually, uncovered whole beast, cleaned it from dust and powered up.The scope surprisingly started, WOW. I made some measurement and turned it off. Few days after i tried to power up again, but the scope didn´t started properly. Sometimes just diagonal traces and unreadable readout characters appeared and few leds were lighting. Sometimes only some LEDs were present and no display. Another time just the point appeared(timebase not running). So i digged and discovered some bad caps in PSU and mainboard too. The PSU now gives correct voltages. And then begun a series of troubleshooting. Finally i focused into A5 digital board, because all timing, control signals should going from there. But they don´t. I found(according to numbers on the image below) that:1. ONE signal from address bus of a MCU is strange. On pin25 of U2092,(TP506) i measured the signal which can´t drop to logic L due to some reasons. I tried to test the U2480(74LS138), but this was good. The data line A15 is going only into this decoder, and to unused J500 connector.This is the first reason for me to think, that the MCU has a faulty pin 25The signal from the pin 37 of MCU is OK.2. I also measured the signal on MCU IRQ(pin4 on U2092). Straight line, no pulses. They should come from 4020 counter and inverted by 74LS04. The clock signal on U2668(4020) was present, but no pulses on output. Reset input was HIGH. I tested the 4020 and it was also faulty. Replaced with new one, but no change. The reset signal is coming from U2034 which should be clocked by decoder U2480. This decoder doesn´t give any clock signal, probably because of bad signal from the MCU(TP506)This is the second reason why i suggest the MCU is faulty3. The main clock for the MCU is OK.4. I found that one data line(D0, pin 33 on MCU) has strange oveshoot, different from another 7lines of data bus.This is the third reason why i suggest the MCU is faultyGuys, do you think my suggestion of faulty MCU(U2092) is right? Is there any chance to get somewhere the main MCU?I hope somebody can help.

author: mij59
author_rank: Frequent Contributor
timestamp: April 11, 2015, 09:04:02 am
content: The microprocessor not running properly could also be caused by a faulty eprom.

author: PA0PBZ
author_rank: Super Contributor
timestamp: April 11, 2015, 01:52:30 pm
content: Quote from: stephunk on April 11, 2015, 08:17:02 amHow did you test it? I'd start by replacing it.

author: MarkL
author_rank: Unknown
timestamp: April 11, 2015, 01:59:52 pm
content: 1) I agree address line A15 (pin 25) looks suspicious. What test did you perform on U2480 (74LS138) to determine it was ok?2) 4020 RESET forces all outputs high, therefore no pulses on output.3) Ok. The fact that the E line (pin 37) is a square wave would confirm that.4) What "strange overshoot"? Screen shot of that?Did you try the "Kernel NOP Diagnostic Procedure"? It's in the troubleshooting flow chart section and there's a description under "How to Verify the Control Data and Control Clock Lines".Also, your voltage levels on your screen shots would indicate you're using a x1 probe. The curves on what normally should be good square waves say that you're probably loading (and interfering with) the signal too much. Use a x10 probe.

author: Fraser
author_rank: Super Contributor
timestamp: April 11, 2015, 02:03:07 pm
content: The good news is that microprocessor failure is rare unless they are abused in some way. I agree with others, do not blame the microprocessor yet.Aurora

author: stephunk
author_rank: Contributor
timestamp: April 11, 2015, 03:33:03 pm
content: Thanks to all, dear members.1. 74LS138 was tested separately on the breadboard-i just checked if the performance matches the truth table. I also measured input currents of control inputs(were as small as the datasheet says). I always test the possible faulty logic IC separately on the breadboard.2. I did not perform the kernel NOP diag procedure yet, but i try this.3. The picture of "overshoot" i can upload this evening. Overshoot is not the exact word for this phenomenon. I´ll do this right after kernel diagnostic.4. sure I hope(and PRAY) the MCU is Ok. Rarely, but also on modern MCU´s there is possibility, that entire chip is working fine, but some pins are blown due to various reasons, reason no1 is ESD. Maybe I underestimated this, when brushed the board from dust with toothbrush. However, this never happened to me(maybe this is the first time)But the failure appeared before brushing.

author: PA0PBZ
author_rank: Super Contributor
timestamp: April 11, 2015, 03:47:46 pm
content: Even if the A15 line is blown it still shows some activity. I guess it could be fixed by being a bit creative with buffering and pulling.

author: stephunk
author_rank: Contributor
timestamp: April 11, 2015, 04:37:09 pm
content: So the diagnostic is done. Every address line gives nice rectangular signal. Only A15 has incorrect logic zero level. It drops only to a half of the supply voltage. So this is similar when a mother asked her little daughter if father is sleeping, she answered: Yes, whole daddy is sleeping, excepting his noseNow it´s time for pulling it downThank you again

author: MarkL
author_rank: Unknown
timestamp: April 11, 2015, 06:54:46 pm
content: What I would do at this point, if the processor is socketed, is unplug it and then put it back in with A15 hanging out. Then you can test A15 in NOP mode with the assurance that nothing else is interfering with it. You'll have to be the judge if the package can tolerate bending the pin sufficiently to do this.If the processor is soldered, then I would carefully snip the A15 pin to isolate it, and then do the NOP test. Make sure you leave enough pin so you can solder it back together again. This method is a bit crude, but if you're looking at a processor replacement you may end up doing this to all the pins anyway.

author: edavid
author_rank: Super Contributor
timestamp: April 11, 2015, 07:25:31 pm
content: FYI, if you need to replace the 68A08, you can also use any of 68A02, 68B02, or 68B08... 68B02 is probably the easiest to find.

author: MarkL
author_rank: Unknown
timestamp: April 11, 2015, 07:51:06 pm
content: The manual lists the processor as a Tek #156-1342-01 which is a Motorola SC67127P. From what I can find that's a Mil spec 6802.A 156-1342-00 is a MC-6802P, so that should work too, to add to your list.I'm not sure where where the OP got S68A08. Maybe read it off the chip.

author: edavid
author_rank: Super Contributor
timestamp: April 11, 2015, 08:46:36 pm
content: Quote from: MarkL on April 11, 2015, 07:51:06 pmIf there's a 1.5MHz CPU in there now (68A08), I wouldn't really want to downgrade to a 1MHz part (6802), when the faster parts are readily available.

author: MarkL
author_rank: Unknown
timestamp: April 11, 2015, 09:23:37 pm
content: Quote from: edavid on April 11, 2015, 08:46:36 pmFrom the scope trace on the E line, it looks like it's running at 1.25MHz (5MHz clock input). And Tek has the internal RAM disabled so '02 doesn't matter.You're right. My mistake for not digging into the clock speed more closely. Was just reading off the parts list.

author: stephunk
author_rank: Contributor
timestamp: April 11, 2015, 09:48:52 pm
content: Yes, the MCU is clocked on 5MHz.MarkL: You´ve got th point. If pin25 is hanging free, this only one gives a logH 3,8V and log L is really near 0V(so the pin25 is probably good!). Other pins are giving 4V(LogH) and near 0V(LogL). If we follow the schematic, this pin goes only to 74LS138 pin3, which is one of three select inputs.Next interesting thing, while pin25 unconnected, some voltage on pin3 of 74LS138 was present.. I unsoldered it and put in onto breadboard. I can´t believe my eyes. With just Vcc and GND connected, i measured various voltages on all its inputs which is around 4V(Vdd is 5,01V and perfectly stable). I connected the resistor 10k between GND and any input. The voltage dropped to 3,7V. With 680R resistor I measured 175mV. With 2k7 1,5V. I found this on 2 new(!) pieces of DM74LS138. There is some voltage on every input, and this voltage depends of the value of resistor connected between input and GND. It yields, that input currents are 200-500µA...This is a big surprise for me. Never see it before..i should to keep the original TI SN74LS138 and don´t throw it..The new chips have an old logo of National Semiconductor. It´s time for rest and beer hereAgain, thanks to you all

author: MarkL
author_rank: Unknown
timestamp: April 11, 2015, 10:26:39 pm
content: The LS138 has a logic-low drive current max of 0.4mA @ Vinput of 0.4V (TI LS138 datasheet). Keep in mind these are intrinsically bipolar devices and not CMOS, so they're going to draw noticeable current on the inputs.It hasn't been ruled out that the processor A15 output is not driving hard enough, or at all, to ground. The output should be able to sink 1.6mA and keep the voltage below 0.4V (according to the 6802 datasheet).When you're done rest and beer, I would next try connecting a 3.3k resistor from A15 to +5V and see if you get <0.4V for logic low while running the NOP test. It should actually do much better than 0.4V, but 0.4V is the max spec.If it can't sink the voltage to below 0.4V, I'm afraid it's time to find a new processor or try PA0PBZ's workaround buffer idea. If the '138 is the only thing on the A15 pin, I suppose you could also try a 74HCT138, which *is* CMOS and would draw close to zero input current.EDIT: 3.3k resistor to +5V, NOT ground. Maybe I need rest and beer too.

author: stephunk
author_rank: Contributor
timestamp: April 12, 2015, 07:02:22 am
content: Yes, you are absolutely right. The pin25 can´t sink enough current so with 2k7 resistor it drops only to 3,6V. I built a small schmitt trigger circuit with 2gates of 40106 and 2 resistors. I can set the treshold voltage easy. Next thing is to put this into the circuit. There is some delay what is caused by relatively slow cmos circuit, maybe 74HCT14 would do the job better..EDIT:the most effectively way would be to use 74HCT138, i run to shop and pick few. I don´t want to put some nest into such beautiful instrument.

author: MarkL
author_rank: Unknown
timestamp: April 12, 2015, 03:37:26 pm
content: You must have a good shop that has 74HCT138 in stock.If you go with the 74HCT138, you might need a pulldown resistor on A15 to help it get low enough, depending on how damaged the output MOSFET is inside the processor. You could try something from 35k to 100k, but you might need to experiment to find the right value.Really the right fix for this is to replace the processor, if at all possible. A search on possible replacements (from edavid) show that they can be had, and are not outrageously priced.

author: stephunk
author_rank: Contributor
timestamp: April 13, 2015, 04:37:52 pm
content: Shop is quite good, but not the bestI work there as seller, therefore i can get almost everything also at midnightI found only 74HC138 but for our purpose it works. No pull-up is needed. Scope is already starting, but there is an error message(test04 fail, error 11), which indicates some trouble with EAROM and associated IC´S and transistor. This is what i was worrying the most, right after MCU failure. So, the challenge goes on! EAROM contains data which represents the last working configuration of the scope right before turning the scope off. So if the scope is powered up again, the front panel settings are loaded. Wondering what else will jump on me..Hmm, in normal operation i found noisy data line D0(but there is some activity too). In diag mode, this only one is in High state. Im going to test U2194 74LS244.

author: MarkL
author_rank: Unknown
timestamp: April 13, 2015, 08:01:28 pm
content: Quote from: stephunk on April 13, 2015, 04:37:52 pmDiag mode executes NOP instructions. The 6802 NOP instruction is 0x01, so in diag mode D7-D1 are 0, and D0 is 1.I would take a look at the suggestions in the manual for Test 04 Error 11: U2118, U2208, U2108, Q2025.If the scope is running enough, you could also try the EAROM exerciser (exerciser 02) to see if there's any data in the EAROM.Not only does the EAROM contain your last settings, it also has your calibration data. You want it to be working.

author: stephunk
author_rank: Contributor
timestamp: April 17, 2015, 12:01:53 am
content: Hmm, i have to say that i am not so familiar with the digital stuff like MCU and memories, but i found something what is for me totally weird. There is a HM6116P-3 which is 2kx8bit fully static RAM. In the breadboard i connected the control inputs:20. OE(neg) to Gnd21. WE(neg) to +Vcc18. CS(neg) to Gnd So the device should be selected, and in read mode. Right?Address inputs are not connected(so i estimate the input address is choosen 000h). The device doesn´t require any timing signals, is in the read mode and outputs should show the DC voltage 0V or Log1(am i right?).Is it possible to measure a squarewave signal of period 20ms ONLY on I/O0(pin 9)?? It´s like inducing the 50Hz into the chip structure, but other I/O pins remains at Log0. The period is slightly changing and the duty cycle of the signal rapidly changes, when i make a pressure on the package with my finger. I took a pictures of this..it´s time for bed i think. Do the address lines need a pull-up resistor? I think these are schmitt buffered inputs..BTW, tomorrow the EEprom´s are going to be tested also.

author: edavid
author_rank: Super Contributor
timestamp: April 17, 2015, 12:33:38 am
content: Floating the address lines is very bad practice and can lead to strange behavior.

author: stephunk
author_rank: Contributor
timestamp: April 21, 2015, 12:12:15 am
content: You are right Edavid. I´m trying to improve myself so i build a TTL logic tester with ZIF socket. Each pin can now be connected directly to Vcc, Gnd, or to Gnd via 4k7 resistor. With this tester i found that HM6116 has its outputs OK(i programmed 3 addresses with 3 different words and read it back). However i can´t prove, that whole memory matrix is OK. My good friend has a programmer for 2764 UV-EPROMS and we´ve made a dump of each one. No errors during reading of these. Has anybody information if dups of these 2764´s are available somewhere, just to compare if mine are OK. It would be fantastic

author: MarkL
author_rank: Unknown
timestamp: April 21, 2015, 12:50:45 am
content: There's a set of ROM images for the 2445 here:http://www.ko4bb.com/manuals/download.php?file=01_ROM_Images_and_Drivers/Tektronix_2445_Eproms.zipIn the zip file there's a notes.doc. You should read that to make sure you're comparing the same versions.By part number, the 2445 appears to have the same EPROMs as the 2465. So, you could look at some of these:http://www.ko4bb.com/manuals/index.php?dir=Tektronix/Tektronix_-_2465_OscilloscopeIf none of those match, try searching for "rom image" and the number on the sticker on your EPROMs.Why do you think the EPROMs might be bad? The scope was complaining about the EAROM, unless something new has cropped up.

author: stephunk
author_rank: Contributor
timestamp: April 21, 2015, 11:20:12 pm
content: MarkL: thank you again for the link, although my EPROMS have different numbers. This forum is fantastic, because of its kind and willing users. I found the faulty EAROM driver MC1413-output of driver B is blown(pin15 always conducts to Gnd) and one driver doesn´t work(pin16). This could be the problem, because this particular pin drives inverts the pwr down signal from PSU for the MCU. Tomorrow i´ll bring some ULN2003 and see if this will work.

author: mskobier
author_rank: Regular Contributor
timestamp: April 28, 2015, 02:53:47 am
content: stephunk,Its been a few days since your last post. Have you made any headway in resolving your issue with the 2445? I ask because I am having a very similar problem with the second 2465 I will start troubleshooting on again soon.ThanksMitch

author: stephunk
author_rank: Contributor
timestamp: April 28, 2015, 06:12:36 am
content: Hi MskobierI tested every IC which is connected to data, and address bus excepting the U2134/2034. I soldered the MCU directly to the PCB to make sure the socket is not the problem, but the problem remains. Sometimes the A/B trigger flashes, sometimes few leds lights, and sometimes(rarely) i can see the display, but timebase not running and scope doesn´t respond to any key.. Now i am suspecting the EAROM itself, or the MCU. Next step is to make a tester for the EAROM and try to get some data from it. Good luck with your scope!Edit: The fight is over, MCU is definitely dead. Also in Diag mode, there is no activity on the address bus. In detailed wiew the surface of the pins is oxidated, and i think this oxidation bites into the package and gradually damaged internal pinning. Maybe it was just a matter of time, when this happens. Maybe the bad ESD care was made from my side. And maybe combination of these two things. I´ll try to get MCU programmed for my A5 board version, or the whole A5 board..BTW thanks to all for help

author: mskobier
author_rank: Regular Contributor
timestamp: April 28, 2015, 06:09:09 pm
content: Stephunk,Bummer on the mcu being toast. Fortunately, they are readily available and cheap! I thinking I have a bad processor or the two ICs controlling the data lines are bad in mine. According to the troubleshooting tree, that's where it leads me, or the ram, rom, or processor is bad. The tree splits there and leads me down either path. I have pulled the roms from my board and read them in the programmer. I then compared the rom contents to a set of known good roms I downloaded from the net. All data was exactly the same, so that rules out the roms. So that leaves the processor, ram, or the two data control IC's. I'll get back to this scope in the next couple of weeks. Learning a lot and having fun!.Another poster had said the roms in the 2445 and the 2465 are the same. If so, you are welcome to a copy of the bin files that I read from my roms so you can compare data. Just let me know.Mitch

author: PA0PBZ
author_rank: Super Contributor
timestamp: April 28, 2015, 06:15:29 pm
content: Quote from: stephunk on April 28, 2015, 06:12:36 amI don't think the MC6802 has a rom, so not sure what you mean by 'programmed'?(you say S68A08 but the schematics show MC6802?)

author: MarkL
author_rank: Unknown
timestamp: April 28, 2015, 06:57:45 pm
content: Quote from: PA0PBZ on April 28, 2015, 06:15:29 pmYou're right, it does not have a ROM (or flash).08 parts are identical to 02, but 08 doesn't include the on-chip 128 byte RAM. Tek has the RE (RAM Enable) input permanently low, so the internal RAM is never enabled anyway, hence allowing use of either part.A versions are 1.5MHz, B are 2.0MHz, and no letter is 1.0MHz. From earlier in this thread we figured out the cycle time is 1.25MHZ so we need at least an A part.I have no idea why the schematic and parts list says vanilla 6802. It threw me too.

author: stephunk
author_rank: Contributor
timestamp: April 28, 2015, 09:10:07 pm
content: I didn´t study the datasheet for 680X family in details, because as it is a microcontroller, i thought it has to be programmed. This is a part of electronics where i´ve got a lack of experience and also this device itself is older as meSo, if i will somehow get the MCU, put it into board, and everything other is OK, should my TEK be alive again?And yes, the schematic says MC6802(Motorola), but on board is S68A08P(AMI semiconductor).

author: edavid
author_rank: Super Contributor
timestamp: April 28, 2015, 09:27:00 pm
content: Quote from: stephunk on April 28, 2015, 09:10:07 pmIn the old days we would distinguish between a microprocessor (MPU) and microcontroller (MCU). The 6802/6808 is an MPU, not an MCU.

author: MarkL
author_rank: Unknown
timestamp: April 29, 2015, 12:20:24 am
content: Quote from: stephunk on April 28, 2015, 09:10:07 pmAnything's possible. I thought you had it partially working before with the 74HC138 with the EAROM errors. I think the scope will still run with a bad EAROM while you debug it (although you will have power-on errors).It sounds like there are now other problems, and you've disturbed a fair number of components. I think the chances of popping in a new processor and having it work are not as good.But don't get me wrong - if you find one, you might as well try it. From prior testing you know for sure it was bad. I just think you have more troubleshooting ahead of you.

author: stephunk
author_rank: Contributor
timestamp: June 01, 2015, 08:24:10 pm
content: The new MPU´s arrived few days ago. I ordered MC68B02P, put it into socket and tradaaa, i have the readout and the trace both. I need to check the performance in details now.Best wishes to all of you sirsand thank you for your help. I learned a lot with this scope!

author: MarkL
author_rank: Unknown
timestamp: June 01, 2015, 09:08:41 pm
content: That's great! With no power-on errors now?Hopefully your calibration is intact too and it was all a processor issue.

author: stephunk
author_rank: Contributor
timestamp: June 01, 2015, 09:52:23 pm
content: Failed test 04, error code 11. So there is an issue with earom, bad checksum and/or parity error on read..By pressing A/B trig, it turns into normal operation. Tomorrow i´ll look closer again

author: mskobier
author_rank: Regular Contributor
timestamp: June 02, 2015, 04:09:49 am
content: Stephunk,I have an early version 2465CTS that I have copied the roms to BIN files. For most purposes, they should be the same as is in your 2445. If you are interested, I can send the files to you to try and replace your current corrupt roms BINs. The one I have has four roms. I also have a later (I think) A5 board that only uses two roms. I have not copied them, so I do not know if they are good. After I copied the roms to file, I compared them to what is supposed to be known good versions I downloaded from the net. The files matched perfectly, with no differences in the code for all four roms. Something to keep in mind, is that the roms in that model of scope are UV roms. What that means is that they can only be written to once. If the data needs to be changed, then the entire chip needs to be erased using a UV light source. Then the chips can be reprogrammed via normal programmer. I haven't looked lately, but I think those chips are still available, at least in NOS.Let me know if you want the BIN files.Mitch

author: stephunk
author_rank: Contributor
timestamp: June 02, 2015, 08:31:04 pm
content: MskobierI already have some bins from 2465, and it doesn´t match.I´ve got installed this UVEPROMs: 160-1625-06,160-1626-06,160-1627-06,160-1628-06. I think, that each such numbered part has its own unique content.. So if you have 2 chips, i.e. 160-1625-04 and 160-1625-06, dumps from these two will be different. I proved it right now, using Vbindiff tool. However i am looking forward to your dumps, feel free to send it. I´ll be glad

author: mskobier
author_rank: Regular Contributor
timestamp: June 03, 2015, 01:42:21 am
content: Stephunk,What I meant was that the code from each of the rom chips matched the downloaded rom files, not that they all had the same code. So rom 05 from my scope matched the rom 05 that I downloaded. The same for 06, 07 and 08. The bin files are in another computer that is in another location. I'll get them copied and send them to you. It will be early next week before I can get to that computer.Mitch

author: MarkL
author_rank: Unknown
timestamp: June 03, 2015, 02:49:19 am
content: As explained in the "Diagnostic Routines" section in the "Troubleshooting" chapter, the ROMs are tested with a checksum on power-up, before the EAROM. They're fine since no error regarding them was displayed.Do you have some other indication to suspect them?If not, now that the processor is replaced, I would suggest rewinding your testing to post #18:https://www.eevblog.com/forum/repair/tektronix-2445-bad-microprocessor-s68a08/msg651562/#msg651562And try to find the problem with the EAROM. Your cal data may still be in there, but inaccessible.

author: stephunk
author_rank: Contributor
timestamp: June 03, 2015, 05:53:24 pm
content: I don´t suspect the UVEPROMs any more, since i powered up the scope with new MPU. Everything is clear. Scope is running with error message related to EAROM and associated circuits. I am just curious, if the UVEPROM dump from Mskobier is same as mine or isn´t.In case of EAROM related error message one can assume, that there is error in checksum(maybe i lost calibration data), or parity error. Next fact is, that 1V amplitude is displayed as 10V.. i keep going to studyBTW, I did exercise 02, and read content of some addresses. There are some data, but at this point i don´t know, if these are correct.

author: MarkL
author_rank: Unknown
timestamp: June 03, 2015, 06:46:50 pm
content: Quote from: stephunk on June 03, 2015, 05:53:24 pmThere's hope!If you decode the hex values, do you notice if any bits are always stuck as a 0 or 1?Only locations 0x00 to 0x63 are used, and they are a 14-bit words (so the top 2 bits will always be 0 anyway).In particular, cal data is stored at locations 0x01 to 0x4C and are also a 14-bit word, but with 13 bits of data and one bit of odd parity.Details in the in the "EAROM Exerciser" section.EDIT: No!! I got that wrong. I was thinking this EAROM had a nibble bus but it does not. It's purely serial. Sorry about that.It might be useful to know, however, if there's any pattern to the failed values (like all 1's), especially in the cal data, or if the read back values are not consistently the same each time.It's possible the contents may just be corrupted.

author: mskobier
author_rank: Regular Contributor
timestamp: June 04, 2015, 03:08:56 am
content: Stephunk,I got a chance to get to the other computer this evening. Here are the BIN files if read from my UVROMS. Hopefully they are of some use to you.Mitch

author: stephunk
author_rank: Contributor
timestamp: June 04, 2015, 05:58:39 am
content: MarkLYesterday i ran the exerciser02 and each time I read the EAROM content i can see the same values. Every value has a maximum 14bit width. Every calibration constant has odd parity, but the last one, on address x04C has 0082 value with X(EVEN parity). In the entire range of cal data(x01-x4C), there should be odd parity everywhere i guess, am i right?MskobierThank you, i´ll check this in the evening.

author: MarkL
author_rank: Unknown
timestamp: June 04, 2015, 08:26:51 pm
content: Quote from: stephunk on June 04, 2015, 05:58:39 amRight, 0x01 to 0x4C should all be odd parity with no "X" displayed.Looking back at the error, "FAIL 04 11" is a parity error and a checksum error on the cal data.If the parity for locations 0x01 to 0x4B are ok and it looks like there's reasonable data in there, chances are good that it's complaining about that one location, 0x4C.A "spiral-add" checksum for all the cal data is stored at location 0x00. So, if we know the checksum and we know there's only one bad word, it might be possible to reconstruct the bad word. I don't know exactly what algorithm they mean by "spiral-add", but it could be figured out. But then the problem is how to write the correct word back to the EAROM at 0x4C. That could be done too, but it's not trivial.It would also be useful to know what location 0x4C affects. Watching the EAROM address for 0x4C while changing settings on the scope might shed some light on it since the scope will access that location when it needs to know the number.I had an EAROM on a 2465 that was reading out bad constants some of the time. Providing the EAROM with a slightly lower operating voltage allowed me to dig the constants out, but since you're getting consistent results, that's probably not the case here.And last but not least, there's always going through the standard calibration procedure to rewrite the value.If anyone knows of a hidden menu to write arbitrary stuff to the EAROM, let us know!

author: MarkL
author_rank: Unknown
timestamp: June 04, 2015, 08:46:32 pm
content: Quote from: stephunk on June 03, 2015, 05:53:24 pmIt might be related to the EAROM.Care to elaborate a little on how this test is set up? A factor of 10 could just be a display factor that's wrong for the probe being used.

author: mskobier
author_rank: Regular Contributor
timestamp: June 04, 2015, 10:03:16 pm
content: All,A quick question. I had the understanding that once this type of rom was written to, you had to use the UV light to erase the chip before you could write to them again, or change any data on the chip. If that is so, how does the scope re-write to the chip when you perform a calibration?Mitch

author: MarkL
author_rank: Unknown
timestamp: June 04, 2015, 10:15:45 pm
content: The EAROM (U2008) is an old incarnation of what would be called an EEPROM today. That's where the cal data is stored. It also holds the front panel settings.The scope operating system is stored in separate EPROMs (U2162, U2378, and in earlier models also U2362, U2178), which have the UV erasure window.EDIT: I meant to say "incarnation", not "implementation".

author: MarkL
author_rank: Unknown
timestamp: June 05, 2015, 06:36:57 pm
content: Quote from: MarkL on June 04, 2015, 08:26:51 pmI connected a logic analyzer to the EAROM of a 2465 (which uses the same operating code as the 2445), and I'm unfortunately unable to figure out what settings cause reads from location 0x4C.I can see that it's being read once on boot, along with a somewhat random group of other locations. And then it's read again in sequence with the other cal locations. The second access is no doubt the parity and checksum confidence tests.Then it's never read again no matter what settings I try.If anyone else wants to try, I found that Tek swaps the 10's and 1's place of the EAROM address. So, location 0x4C (decimal 76) is actually stored at EAROM address 67. It's easy to verify you have everything connected properly by using the EAROM Exerciser.This 2465 has GPIB and CTT options, so it may have also something to do with that. Who knows.

author: MarkL
author_rank: Unknown
timestamp: June 13, 2015, 04:04:19 pm
content: Quote from: MarkL on June 04, 2015, 08:26:51 pmI was interested in figuring out this "spiral-add" algorithm, so I took a look with a logic analyzer and a disassembled version of the 2465 EPROM. For posterity, I've attached a C rendition of the algorithm.What's interesting, as it applies to your parity error, is that the Tek code truncates the checksum at EAROM 0x0000 to 8 bits instead of preserving all the bits. No idea why.In doing so, the recovery of a bad 13-bit value at your EAROM 0x004C is likely going to have multiple possible values that map to the same 8-bit checksum. There's no definitive way to tell which combination is the right one.Although it's not guaranteed there *must* be multiple solution values, chances are not good there's only one. It depends on your specific EAROM data. The only way to know is to use your actual data and compute all the possible solutions.And I still don't see where EAROM 0x004C is used. It would still be nice to know if this value even matters. Now that I have the code disassembled maybe I'll poke at it a little more.But I'd say it looks like it's time for a re-cal to clear this error.

author: MarkL
author_rank: Unknown
timestamp: June 15, 2015, 08:53:11 pm
content: Quote from: MarkL on June 13, 2015, 04:04:19 pmOk, I think I've got this piece figured out too.EAROM location 0x4C, as mentioned before, gets read at boot time.More digging with the code and the logic analyzer shows that once it gets read, it's stored in RAM as a word at locations 0x010F and 0x0110 (MSB then LSB).RAM 0x010F/0x0110 is then accessed whenever the delta-V button is pushed and the horizontal cursors appear, no matter what traces are currently on the screen.This leads me to the conclusion that EAROM 0x4C is the calibration constant that is derived in steps "a" and "zz" in the "CAL 02 VERTICAL" adjustment section.So, stephunk, I would expect the only thing this bad value is affecting is the delta-V cursors. Unfortunately, it's only set at the very end of the vertical cal procedure, so I don't think it's possible to do a cal just on that. You'd have to go through at least the vertical cal, and the manual doesn't generally recommend doing partial calibrations anyway unless you're sure the previous calibration sections are ok.The only other thing I think you could do is build a circuit to write values to the EAROM, and then try different values that 1) makes the the delta-V cursors work properly, and 2) satisfy the checksum algorithmBut that's a lot of work. It's easier to buy or find someone with the needed signal generator to do the cal. Maybe search around for people who have done ad-hoc solutions to calibrate these 24xx scopes.I think I'm done. I seem to be the only one left in this conversation.EDIT: Added pic of 2465 being probed. Fun!

author: stephunk
author_rank: Contributor
timestamp: June 16, 2015, 06:02:03 am
content: MarkLI am watching your progress and now, i´m loosing words. You´ve got my all respect!Calibration procedure cannot be done here, because i don´t have the proper time mark generator. I do have only Philips function generator <1MHz.I am working on a simple circuit, controlled by buttons, which gives necessary clock and data impulses into EAROM and giving the proper logic levels to C1, C2, C3 mode inputs. I need to modify only one address, so i can do it manually only with buttons..I already found, that word 0300(HEX) on this specific address location makes the checksum same as stored on 0x00.(using your algorithm).Everything in the scope is OK, but channel A shows 10x amplitude. This has to be something wrong with sense ring circuitry, i assume nothing serious.Again, thank you for your help, I appreciate it much!

author: MarkL
author_rank: Unknown
timestamp: June 16, 2015, 02:06:42 pm
content: Thanks, glad to know you're still engaged!Here's another thought. I noticed that TEST 04, before it goes through all the locations to check parity and the checksum, does a write test to EAROM location 99 (0x63). On my 2465 it erases 99, writes 0x1555, and then reads it back.It should be fairly easy to find this piece of code and modify the EPROM so it will write whatever you want to any location in the EAROM.Do you have access to equipment to erase and reprogram a 27128 or 2764 (depending on which you have in your scope)? You could create a modified EPROM, boot the scope so it writes the value you want to EAROM 0x4C, and then put back the old EPROM.If you want to do this instead of building an external circuit to control the EAROM let me know. I would need to know what version of EPROMs you have in your unit, and possibly get a copy of the image from you if I don't have it or can't find it anywhere.On the x10, I think you're right and I'd start looking at ring sense circuitry.EDIT: This is a little bit wrong.Actually what the write test does is read the current value at 0x63, invert the bits, erase, write the new value, then read back. This makes more sense since just writing and reading the same value each time won't reveal a bunch of possible problems.So, the value at 0x63 alternates between 0x1555 and 0x2AAA. I didn't catch it before because by chance I was capturing every other run.It's probably not of major importance to anyone, but I don't want to leave bad information out there if I can help it.

author: stephunk
author_rank: Contributor
timestamp: June 16, 2015, 04:06:56 pm
content: MarkLI don´t want to bother you. But thanks anyway, you are very kind. I try to make my programmer. It´s easier for now.

author: MarkL
author_rank: Unknown
timestamp: June 16, 2015, 04:08:14 pm
content: Ok, good luck! Let us know how it goes.

author: mian2zi3
author_rank: Contributor
timestamp: June 17, 2015, 04:11:41 am
content: Quote from: MarkL on June 15, 2015, 08:53:11 pmFun! Would you mind describing your setup? I'm currently in the market for a LA for exactly this type of thing.

author: MarkL
author_rank: Unknown
timestamp: June 17, 2015, 02:11:02 pm
content: The two pieces of equipment I used was an Agilent MSOX3104A mixed-signal scope and an HP 1631D logic analyzer.In the picture, on the right, the MSO digital inputs are connected to the EPROM address lines and the analog probes are connected to the EAROM. The analog inputs were used because the EAROM inputs are at 33V.On the left, the 1631D is connected to the processor address and data bus lines, plus clock, VMA, and RD/WR.At first I was only looking at the EAROM with the MSO to see what was being read and written. Triggering was set up on specific serial EAROM addresses and data bytes. Then I wanted to know what code was doing the access, so then I connected the MSO up to the EPROM address lines. Unfortunately, the MSO only has 16 digital inputs so I couldn't see the data bus at the same time.So, then the 1631D was then connected up to all 16 address and 8 data lines so I could do some stateful tracing of the code and trap values as they were being stored to SRAM. At times the serial decode trigger output from the MSO was used as the arming trigger for the 1631D.If you're starting out wanting to do this kind of digging, I honestly wouldn't recommend the 1631D. It has a miniscule storage of 1024 events and the UI is slow. I used it because I had it laying around from Z80 development I did years ago. What I do like about it is that it has a 43 bit wide input and a plain-language multi-level trigger set up.The scope has good serial triggering abilities, but it's really bad at stateful analysis.If I wanted to do more of this type of work, I would probably look seriously at getting an HP/Agilent 16x00 series modular analyzer, most likely a 16702B, and a state/timing module with lots of capture space like the 16741A with 4Mpts. There's scope modules available for it too, so you can get correlated analog traces. If buying used, make sure you get any cables and probing pods that go with it since those can be difficult and/or expensive to replace.If you're looking lower cost, I always thought the advanced triggering capability of the OLS logic sniffer was pretty good, but there's no GUI for it that I'm aware of:http://www.mygizmos.org/ols/fpga.html(And I'm talking about an ADVANCED trigger GUI, not the standard SUMP GUIs that are out there.) But given the way used LA prices have been dropping, you might be able to pick up something would support a 16550 module for not much more then the OLS anyway.Whatever you might choose, the key is being able to capture all the address and data lines plus some control lines. And the more limited it is on memory, the more sophisticated the triggering should be, at least in my opinion, so you can preserve those events that are important to the task at hand.EDIT: Fix mangled URL, scope model num.

author: DC1MC
author_rank: Super Contributor
timestamp: December 11, 2018, 09:36:01 pm
content: I want to quickly thank to all the people that contributed to this post, I've got a 2465 with the exact same crappy CPU model, mine is made by AMI ?!?!, same picture, same corroded crap and dead as a brick.I've ordered some 68B02 and hopefully I'll have a nice Christmas surprise.I'll definitely plan to use a solid box knife and pry open the dead CPU, it seem that the upper and lower part of the package were joined in a miserable way and that caused the problem.Cheers,DC1MC

author: DC1MC
author_rank: Super Contributor
timestamp: December 27, 2018, 10:31:08 pm
content: Here is my modest contribution for other people if they need them, my Tektronix 2456 A5 board EPROM 4x8KB dumps with the following ID:160-1625-06160-1626-06160-1627-06160-1628-06S/N of the scope: B020XXXIn this thread there is another set, from an older S/N, with xxxx-04 at the end, a binary comparison showed that they are really strongly different.Maybe it helps somebody.Cheers,DC1MC