Attempting repair of TDS540C - Option 1G - Fail Processor - Page 1
Forum section: electronics / repair

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 18, 2019, 10:25:36 am
content: Hello, I'm on my learning curve on repairing and/or upgrading TDS500-700 C and D series.As of today, I do have two of these, one TDS540C 500MHz - 2GS/s which works pretty good and another one with option 1G.Not sure if the 1G or standard 2G is important here, the 1G has failed messages at start, please see 3 pictures attached in this thread.Any idea, suggestion on how to solve at low cost the main issue (Failed Processor) then SPC issue ?Thank you, Albert

author: shakalnokturn
author_rank: Super Contributor
timestamp: December 18, 2019, 11:08:10 am
content: The first thing to check for is signs of corrosion on the PCB.If such is the case it is usually a low-cost fix, you could spend countless hours though.Search online there are many discussions on that problem.

author: madao
author_rank: Frequent Contributor
timestamp: December 18, 2019, 11:37:48 am
content: This is a result of dead battery in NVSRAM. It is harmless failure.Replace DS1486 and calibrate him. (Or, you can use dump of other good running TDS540C for him)1G Option, it is better remove this option. but it is already away by dead batterie. Not every option is good. 1G is downgrade.RegardsMatt

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 18, 2019, 11:51:39 am
content: Hello Matt,Do you happen to sell DS1486 or any alternative to find these new ?What does it mean " you can use dump of other running TDS540C "... sorry I'm french so not english native speaking ?Would you know the GPIB sequence of commands to remove 1G option so it will become 2GS/s as the other TDS540C which I've purchased lately on eBay ?Thank you, Albert

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 18, 2019, 01:24:48 pm
content: Hello Shakalnokturn,Just removed the cabinet and took 4 pictures attached here. For the moment I left the accumulated dust in many places but I do not see any rust or issues on the PCB traces.By the way, what is bets method to remove or vent the dust without creating any ESD due to triboelectric effect ?Thanks, Albert

author: radioguy123
author_rank: Regular Contributor
timestamp: December 18, 2019, 02:24:30 pm
content: You can buy ESD free brushes on ebay.The dallas nvrams aren't being made anymore.Don't be fooled by the fake Chinese junk on ebay.This guy sells replacements for the two nvrams.https://www.ebay.com/itm/Tektronix-TDS784D-700x-600x-exact-functional-replacement-for-DS1486-and-DS1250Y/302913384290?hash=item46870b6f62:g:uuwAAOSw9V5bFXZt

author: madao
author_rank: Frequent Contributor
timestamp: December 18, 2019, 02:50:09 pm
content: Yes, DS1486 is actually big problem.Other solution: Use DS1245, but Clock & Date would not running. (DS1486 has RTC) This is a good alternative, if you can forego clock.DS1245 is yet in production.Or, you can cracking NVSRAM and solder battery.1G Option, normally is option saving into NVSRAM, which you can removing with gpib- commando.This was my thinking about it.But one has trying hacking their TDS540C to TDS580C (1GHz) and found one interessing notice.1G is hardcoded. You must soldering correct resistor-ID on your acquisition board for removing of 1G option.You found ID-resistor on botton side of Board. Interessing, i didn't know about it.https://www.eevblog.com/forum/testgear/conversion-of-500mhz-tds744a-to-1ghz-tds784a/msg2834010/#msg2834010Quote from: Galen on December 17, 2019, 11:36:02 pm

author: radioguy123
author_rank: Regular Contributor
timestamp: December 18, 2019, 03:04:34 pm
content: Hi madaoIs that an xray of an actual DS1486 ?Why is the picture title DS1486counterfeit ?

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 18, 2019, 04:22:20 pm
content: Both NVSRAM on the A11 board are DS1486-120 and DS1650Y-100Do each NVSRAM contain batteries or only DS1486 ?What is the role or function of each NVSRAM and do you confirm this explains the FAIL: processor as reported in the attached picture ?If it can help, I do have a perfectly running TDS540C - 2GS/s so would it be worth compare visually side by side the A10 acquisition board to spot the resistor-capacitor in charge to hardwire 1GS/s

author: madao
author_rank: Frequent Contributor
timestamp: December 18, 2019, 04:41:00 pm
content: Quote from: radioguy123 on December 18, 2019, 03:04:34 pmThis was a china fake DS1486 and runs not stable.

author: madao
author_rank: Frequent Contributor
timestamp: December 18, 2019, 04:45:08 pm
content: Quote from: Tantratron on December 18, 2019, 04:22:20 pmNo, DS1650 contains also batteries, but save only waveform (i am not sure), it is not fatal, if batteries empty.DS1486 save setting , calibration, Option.Quote from: Tantratron on December 18, 2019, 04:22:20 pm1G Option is BAD, normally TDS540C (also TDS754C) runs up to 2Gs/s. (export restriction?)Error message, Diagnostic test failure nvLibrariansDiag, Libs with crcc failures:, ExtConst" and "diagnostic test failure extebded cal librarian reset" It means, calibration constant in NVSRAM is corrupt (CRC fail) and it is resetting to default.I seen, Clock runs fine. Correct ?

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 18, 2019, 05:20:47 pm
content: Quote from: madao on December 18, 2019, 04:45:08 pmYes I've just turn-ON again the scope and the date/time is correct after many days.

author: radioguy123
author_rank: Regular Contributor
timestamp: December 18, 2019, 05:36:18 pm
content: Try and keep running SPC and see if it clears out the errors. I had a TDS540C that had errors until ran the SPC multiple times.

author: james_s
author_rank: Super Contributor
timestamp: December 18, 2019, 06:04:10 pm
content: It's not hard to cut the old battery out and install a new one.On the TDS700 series the calibration is not stored in NVRAM, I don't know for sure about the TDS500 series but I think they are largely the same except monochrome.

author: Alfons
author_rank: Regular Contributor
timestamp: December 18, 2019, 06:34:13 pm
content: Quote from: james_s on December 18, 2019, 06:04:10 pmYes, it creates confusion. One says calibration data is stored in NVRAM, the other says in SRAM. After what I've read, the Cal data in the TDS 500/600/700 series is stored in SRAM and not in NVRAM. Would be nice if we could agree on that.

author: madao
author_rank: Frequent Contributor
timestamp: December 18, 2019, 06:43:04 pm
content: Calbration constant is saved in NVSRAM (DS1486) and a bit cal constant (Bandwitdh & Voltage-reference, only guesting) in I²C EPROM on acquisition board.500 and 700 is same , except of color-displayclock runs fine, it tells you: Batterie is not really empty. You can writing him with good dump of other TDS540C.Quote from: radioguy123 on December 18, 2019, 05:36:18 pmNo, it would not helping, because all calibration except SPC is initialized (= default-value, not good for using)regardsmatt

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 18, 2019, 06:51:43 pm
content: The fundamental question with this scope, the logfile says specific sentence " FATAL: 250 NV storage too small - more bytes requested than available "... see again attached pictureNot sure if both NVRAM have their batteries dead by the one in charge of keeping time-date works fine since the Oscope always provide correct time-date. Maybe it is the 2nd NVRAM who has depleted battery... unless we need to troubleshoot what chip is FATAL failing to logfile " FATAL: 250 NV storage too small - more bytes requested than available "As for the SPC, it states PASS but the other parameters are only INITIALIZED so NOT PASSED, please see again other picture

author: Alfons
author_rank: Regular Contributor
timestamp: December 18, 2019, 07:18:09 pm
content: Quote from: Tantratron on December 18, 2019, 06:51:43 pmThis means: Error log is full, there is no more space for new logs. The memory can be deleted via GPIB. What you can still do: Set OK in the utility menu "Tek Secure Erase Memory". Maybe it helps. This removes all the garbage that has accumulated.

author: madao
author_rank: Frequent Contributor
timestamp: December 18, 2019, 08:04:12 pm
content: " FATAL: 250 NV storage too small - more bytes requested than available "This error is not fatal. Ingored him for at first.Yes, you say, clock run fine -> batteries is not empty. But fact exists: few bit had tilted. Result: CRC failed, -> calibration constant in NVSRAM is gone.Recalibration of him. You got Software for him ->http://www.ko4bb.com/getsimple/index.php?id=download&file=Tektronix/Tektronix_-_TDS5xx_TDS6xx_TDS7xx_Digital_Phosphore_Oscilloscopes/Tektronix_TDS700C_Field_Adjustment_Software_PN_063277401.zipThis software needed old PC with ISA-bus and NI GPIB-PCII or PCIIA.And DCV/I Kalibrator, good DMM.Signalgenerator (Tektronix SG504 and SG503 recommend, i use Rohde Schwarz SMY02)few high quality BNC cable and T- adapterand many time and patient. (5-10 hours)(more info is in Service Manual for 500C/700C)I recommed you, saving dump of NVSRAM from good TDS540C and put it in other TDS540C. Then, you can seeing, "processor fail" disappear.Have you EPROM-Programmer, which can write/read DS1245 (just a DS1486 without clock) or running tekfwtool ? (I know, you use MAC, i have not knowing about it)

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 19, 2019, 04:43:20 am
content: Quote from: Alfons on December 18, 2019, 07:18:09 pmI do not think the issue is about lack of memory to store more info in the log file. Each time I run power, the log file will add with new stamp time/date the error in the log file.Few days ago, I did "tek secure erase memory" which did clear some stuff and the oscilloscope was again able to display signals on all Channels. However this erase did not at all clear the log file content.What is the GPIB command to erase the log file since I've been able 2 days ago to interface my MacBook Air with GPIB-USB device from National Instruments and its Mac OS suite ?

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 19, 2019, 04:58:38 am
content: Quote from: madao on December 18, 2019, 08:04:12 pmHello Matt,Please find my first success to GPIB interface my second TDS540C working with my MacBook Airhttps://www.eevblog.com/forum/repair/gpib-usb-control-between-macbook-air-(macintosh)-and-tds540c/Could you teach me what are the exact chain of GIPB commands for 2 operations.1. Dump NVSRAM from my good TDS540C then upload to the bad TDS540C2. Read the Flags of different options (1M 2M 2F...) then upload the new flags to enable options like 2M or 2F from VISA Interactive Control softwareThank you, Albert

author: shakalnokturn
author_rank: Super Contributor
timestamp: December 19, 2019, 01:46:52 pm
content: Quote from: Tantratron on December 18, 2019, 01:24:48 pmYour photos show mainly tantalum capacitors so that's one problem less to consider.You do have SMD electrolytics on the console serial PCB so take a closer look at those, I don't know if failure to communicate with the UART on this board would cause a "FAIL: Processor", you could always disconnect it to be sure, it is an optional PCB.I'd agree to say that the error log memory is full, each new entry would be pushing the oldest one into oblivion.

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 20, 2019, 07:27:42 am
content: Bonjour Shakalnokturn,Please note for the clarity that I've two TDS540C in my lab, one which I've purchased on eBay working fine and another one which is partially failed.This morning I've removed as you suggest the RS-232 and Centronics optional board from the main A11 board. When starting the scope, now it will not display the Option 13 on the banner so it seems the TDS540C self-detect by hardware the presence of Option 13. Unfortunately I still have FAIL - Processor so there must really something on the A11 processor/display board.By the way, I notice a strange thing when running side by side the healthy TDS540C (2GS/s) versus the failed TDS540C (1GS/s option 1G). When I push to the limits the horizontal scales up to 50ns, the left-top screen will correctly display " tek Run 1GS/s " but if increasing the horizontal speed, the healthy TDS540C will always keep tek run 1GS/s so this strange because normally it should offer 2GS/s standard. However on the partial fail TDS540C Option 1G, I can push to faster horizontal speed up to 100 GS/s at 50 ps except it displays additional ET SAMPLESo one TDS540C has printed 500MHz - 2GS/s whereas the other 500 MHz - 1GS/s Option 1G.... which one is fastest after all ?Anyway sorry for the rambling where the topic is understand how to eventually repair the A11 process or fail which by the ways freezes the SPC initialized.Lastly I really confirm the size of the log file is not the problem, each time I re-run the scope it will add same error estimates with new date and time but keep the oldest log file data from 2003. I'm attaching the historical logfile from 2003 where it seems this Oscope had many problems in the past then kept sitting alone with the last problem, namely Processor failed.

author: shakalnokturn
author_rank: Super Contributor
timestamp: December 20, 2019, 08:36:06 am
content: Not certain as I no longer have a TDS 54x at hand, IIRC the maximum real-time sample rate depends on number of active channels. (2GS/s single, 1GS/s dual, 500MS/s triple or quad?)

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 20, 2019, 08:44:56 am
content: Bingo my mistake... indeed when I tested the healthy TDS540C there was both Ch1 and Ch2 with Math doing Ch 1 x Ch 2Removing all traces and only keeping one channel active provides Tek Run 2 GS/sMerci

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 20, 2019, 01:27:57 pm
content: Hum new unpected failure where after removing the RS232-Centronics PCB then did some soft antistatic ESD kind brushing to remove dust on some parts of the TDS540C oscilloscope... the TDS540C will never turn-OFF complete.Upon pushing the ON/STDY button, the engine fan will constantly try to slightly run then stop then try to spin then stop. Of course no further function will work, no LED, no nothing so for some reason, the uC sees the failed fan hence prevents anymore starting the Oscope.Any idea what connector or could explain the fan engine to not spin or I shall say spin 1° then stop then try spin 1°... ?Thank you, Albert

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 20, 2019, 02:59:52 pm
content: P.S. I have now connected the fan-motor to a 25Vdc power supply, it runs nice so I've re-connected the fan to J20 connector on the A11 board. Just checked now electrical continuity between the J27-1 and J27-3 towards the J20 fan power supply, it seems totally OK. Finally used my DMM to measure the voltage between J27-1 and J27-3, the voltage keeps fluctuating or oscillating between 1V to 3V whereas the service manual states it should be 25Vdc.Would you know if the A11 board with the fail processor board as discussed previously in the thread could affect the PSU or at least affect the Fan power hence blocking the complete start of the oscilloscope ?

author: shakalnokturn
author_rank: Super Contributor
timestamp: December 20, 2019, 03:27:19 pm
content: First check all interconnect if you have removed any.The most common mistake is the side interconnect PCB, it can be reversed but only works one way.Your symptoms indicate PS is overloaded.

author: madao
author_rank: Frequent Contributor
timestamp: December 20, 2019, 03:34:38 pm
content: If fan doesn't run , it would make no error-code . 25V is trough wired of PSU to fan and CRT-unit, nothing diagnostic here.If it run more than 10 minutes, then turn unit off and added one message into error-log. "overheating"I have buyed a TDS754C from Israel, really cheap, with blocked FAN. But seller don't know about it and tell PSU is probably damage.This is why, it was really cheap and easy to repair.Error-logs is very interessing.You can checked on flat cable connection on other side, here a picked schematic of TDS520B ( on this Connector J27 and J26 is same with C & D Serie)

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 20, 2019, 05:50:56 pm
content: OK finally got the scope working again with its fan and of course the initial topic (processor fail).I do not remember really to have disconnected anything excepting removing the RS232-Centronics board to test if it would affect the partial failure.Anyway in order to troubleshoot the PSU over-loaded or whatever made the Fan to not work and no screen, no nothing. I did disconnect both J101 and J700 connector which links the PSU to the acquisition board A11. This time the fan would work, the scope would start but get stuck with all green LED and no screen. I did reconnect J101 only and no fan then I only reconnect J700, the fan starts then stop then starts along with relay clinking and LED blinking. For some reason, I tried again to reconnect only J101 no fan and then suddenly the fan worked, the scope started. At then end I reconnect the J700 and now the scope seems to work.Not sure what happened really but now the scope works again except this damned "processor fail" as we have been discussing from the start in this thread.At least now the scope has been cleaned from all its dust so I'll post some more pictures later.One question I do have now, how can I tell visually from A11 and A10 boards if this scope has pre-installed 8M memories so in theory I could enable the 2M option ?

author: shakalnokturn
author_rank: Super Contributor
timestamp: December 20, 2019, 06:45:06 pm
content: The SRAM IC references on the acquisition board and a little math should tell you that.

author: madao
author_rank: Frequent Contributor
timestamp: December 20, 2019, 07:46:55 pm
content: Installed AS7C164 or similar = 1M OptionAS7C1024 or similar = 2M option.I ask you again: Have you programmer for EPROM (TL866 and other type) ?Yes, heat solder iron and desolder NVSRAM (or: use tekfwtool)

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 20, 2019, 08:53:07 pm
content: Quote from: madao on December 20, 2019, 07:46:55 pmNope I do not have an EPROM programmer for the moment.As for the tekfwtool, I need to check how to compile the C program in my Macintosh (using Xcode) which you mention on the other threadhttps://www.eevblog.com/forum/repair/gpib-usb-control-between-macbook-air-(macintosh)-and-tds540c/msg2836360/#msg2836360

author: james_s
author_rank: Super Contributor
timestamp: December 21, 2019, 12:10:50 am
content: Something I ran into that may possibly be of use here. My TDS784C has the video trigger option which is a board that sits above the processor board. I found that standard IC sockets raised the Dallas chips too high to fit, however low profile machined pin sockets did fit nicely.

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 21, 2019, 03:32:50 pm
content: Quote from: james_s on December 21, 2019, 12:10:50 amThanks james but in this Oscope, I do not have the video trigger board so the A11 processor board sits on the top alone and the A10 acquisition board bottom.

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 22, 2019, 10:45:46 am
content: Quote from: madao on December 18, 2019, 04:45:08 pmIt seems your analysis is correct and back-up by an older threadhttps://www.eevblog.com/forum/testgear/conversion-of-500mhz-tds744a-to-1ghz-tds784a/msg835530/#msg835530However not sure exactly what jumper or resistor should be changed or removed in order to unlock the 1G restriction ?

author: madao
author_rank: Frequent Contributor
timestamp: December 22, 2019, 12:39:23 pm
content: Pleas disassemble your TDS540C w 1G Option and pick A10 Board out.Pleas read Service Manual for 500C/700C Series. It is much step for disassemble to resistor-ID4x ID-resisistor is on bottom of A10 Acquisition board.Location: near 4 golden koax connector to rear BNC connector. Then pleas flip it to bottom , you'll found only one 0 Ohm Resistor on R1061. Added two 0 Ohm Resistor to R1062 & R1063Pic show top-layer of TDS520C/TDS724C A10 Board, location of ID-resistor (of coruse, it is on other layer)

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 22, 2019, 05:02:59 pm
content: OK Matt many thanks for this detailed instructions.I guess best for the moment to focus on repairing if doable "FAIL ++ PROCESSOR" prior spending time to deconstruct totally the A10 acquisition board. Good to know now that this A10 has many components on its other face, I did not notice this first time I removed the cabinet. In fact the A11 processor board seems to have as well components on its other face... ouch !With your information, now I understand why the 1M option offers 500K of memory because I did only count 32 memory chips AS7C164 which only made 256K. Now I see 32 mores AS7C164 using a flash light on on the A10 other face which makes the 500K count correct.I assume then that all TDS540C with 8M of memory (option 2M) would have a slightly different A10 board because the AS7C1024 has 32 pins versus 28 pins for AS7C164. The soldering of these AS7C wether 8K or 128K cannot be universal with the same PCB foot print traces.Maybe I need a break, tried different things to solve the PROCESSOR FAILOne thing I wonder since this Oscope keeps correct the time, date... how can we be sure both NVRAM would have an issue explainingg the fault ?This Oscope was stored few years it seems at the university unplugged so maybe the internal batteries of this NVRAM's almost died but then why it keeps track of the time stamp.Albert

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 29, 2019, 11:28:18 am
content: Quote from: madao on December 22, 2019, 12:39:23 pmHello Madao,This sunny day morning, I deconstruct the acquisition board of the TDS540C-1G unit per your instructions to find the 4 resistors in charge to allocate 1G 2G, please see attached picture.Indeed there is 0R resistor for R1061 where the 3 other resistors R1062 R1063 and R1064 are openIf I add two 0 Ohm Resistor to R1062 & R1063, do I need to leave 0R on R1061 to enable standard option 2G ?By the way, what is the role of R1064 or more generally, what are the meaning of all combinations of R1061 R1062 R1063 and R1064 ?If I make the 2G modification, do I need to recalibrate the unit ?Do you know if upon starting - booting the TDS540C will automatically remove the 1G display and there is no need to remove the 1G option by software ?Last question, the zoning of R1061 to R1064 shows two IC, these are X24C02 under U1055 and U1052. Are these ICs the EEPROM keeping the factory calibration constant and does firmware update could write-change their content ?Thanks, Albert

author: madao
author_rank: Frequent Contributor
timestamp: December 29, 2019, 11:45:29 am
content: R1064-role ?Four Resistor play a role for ID-numbers. 16 possible combination exists.only R1061 = TDS540C/TDS754C with 1G Limit.R1061,1062, 1063 = TDS540C/TDS754C standard.I don't know about other combination. Possible: only R1064 = TDS580C/TDS784C (not sure..)I don't know about 1G option on software site, you can solder brigde at R1062 and R1063 and let surprised, if 1G is removed.Yes, EEPROM 24C02 hold calibration constant , but not factory calibration constant, it hold current calibration (only partial constant).

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 29, 2019, 12:31:48 pm
content: Quote from: Tantratron on December 22, 2019, 05:02:59 pmStupid mistake of me where now I realize both TDS540C with each 1M option do share the same acquisition board layout for 2M. Upon closer look on the attached picture I took, we see 2x2 additional PCB pad if tektronix would have soldered the 8meg (2M memory option) chipsets. In my case, I do have 1M option so 500K memory using 2x14 chips but the board accepts 2x16 chips hence 8 Meg memory.Do you confirm that all D series systematically solder the 8Meg memories, namely 23 set of 1S7C1014 where we would just play by software enable the no option, the 1M option and the 2M option ?

author: madao
author_rank: Frequent Contributor
timestamp: December 29, 2019, 02:48:45 pm
content: not 100% confirm.Reason: D Serie, from this serie exists 2 version. One old and new. Old look same as C Serie (but not same function), it has AS7C1024.Newer Series uses BGA-housing and much faster synchronus SRAM (same type on Pentium II /III CPU), wich one has 256kb (2Mbitx16) memory. One channel has 8 pieces synchronus SRAM.

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 30, 2019, 09:25:32 am
content: Quote from: madao on December 29, 2019, 11:45:29 amJust soldered wire-strip on resistors then re-assembled the unit. Unfortunately the boot will never complete, all the front panel LEDs stay ON and nothing is displayed on the CRT screen. No choice to go back, de-solder the shorts where it seems hacking 1G to 2G might required software enable or something else on the boards.

author: Jwalling
author_rank: Unknown
timestamp: December 30, 2019, 10:35:40 am
content: Quote from: Tantratron on December 29, 2019, 12:31:48 pmOn the TDS700D series, serial prefix B03XXXX and higher always have 8MB of memory installed. I would think the same is true for 500D...

author: madao
author_rank: Frequent Contributor
timestamp: December 30, 2019, 11:26:15 am
content: Quote from: Tantratron on December 30, 2019, 09:25:32 amImportant: D1 Bus connector, a side with 3 connector (two is empty) must show to CPU board. If side with 3 connector show to acquisition board, it is worng, flip it again.This mistaking with D1 Bus connector happened also by me.It must starting also with worng option and resistor-ID. It doesn't block starting. In few case , TDSxxx is showed.But flipped D1 Bus blocks it. Did you check, calibration switch, it must be protect. ?

author: madao
author_rank: Frequent Contributor
timestamp: December 30, 2019, 11:29:22 am
content: Quote from: Jwalling on December 30, 2019, 10:35:40 ampropably is this notice correct. I have checking my NVSRAM-Dump collection, all above B03xxxx, but only one is B04xxxx.Only TDS714L-case (B01xxxxx), it is excluded, because, it is a "frankenstein" from pre-owner.

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 30, 2019, 11:39:49 am
content: Quote from: madao on December 30, 2019, 11:26:15 amWell I did pay special attention to re-install the D1 bus connector correctly.As for the NVRAM write enable switch S1002, it was always OFF.Hacking or removing 1G option to make it standard 2G might require more modification (HW, SW) but the R1061,1062, 1063 short do not work unfortunately

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 30, 2019, 12:33:05 pm
content: Hello again Matt,Maybe if you have some spare time and access to a TDS500-700 C serie, try the other way around and leave only R1601 shorted to verify if it will down-grade from 2GS/s to 1GS/sAnother option would be to solder wires with remote-jumpers on R1061,1062, 1063 and 1064 then try boot on all 16 combination possibilities.Albert

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 31, 2019, 08:59:46 am
content: Hello again Matt,This morning I've decided to re-open the standard TDS540C Oscope in my lab, namely the one with 2GS/s to check its Acquisition board layout against the TDS540C-1G board which is restricted to 1GS/s. Please see attached pictures of both PCB's as installed, I did not remove this time to see other face.There are some difference between 2G and 1G regarding the 4 resistors: R1061 R1062 R1063 and R1064. With the 2G standard, no need to remove the PCB from the Oscope assembly and we can see your statement to be correct, namely R1061 R1062 and R1063 are shorted with 0R resistor. Take notice of R1066 resistors to be also 0R in both 1G and 2G versions.Anyway both PCB are not exactly the same so I suspect this is why not so easy to hack or convert the 1G to 2G version. What is certain, you're right that the 1G resistors R1061 to R1064 are installed on the other face of the 1G board hence requires more hand work.Albert

author: madao
author_rank: Frequent Contributor
timestamp: January 01, 2020, 05:56:44 am
content: What you have, 2 difference version of A10 Board (also from CPU Board existis two difference version). Resistor on Bottom is newer.679-4039 is old, 679-04204-00 is newer. But this numbers is only 2Gs/s ACQ Board. I guest: 671-3825-01 by your instrument with 1G OptionEDIT:671-3825-01 is seen in few photo from albert.Servicemanual for 500C/600B/700C tells me, only this A10 board is difference.I can checking of Resistor-ID, but i have version with Resistor on bottom.I believe yet, you have put not correctly D1 Bus or other stuff at first try. It is happens also by me. Wrong ID doesn't block starting.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 04, 2020, 11:32:21 am
content: Quote from: Tantratron on December 20, 2019, 08:53:07 pmHello Matt, as you know on other thread and private exchange, I've now success in reading and writing NVSRAM's thanks to compiled version of tekfwtool in my Macintosh where the physical interface is GPIB-USB-HS of National Instruments.I've dumped (read) the 1486 BIN file content from the working TDS540C-2G then wrote this BIN file into the failed TDS540C-1G but it does not solve the FAIL ++PROCESSORMaybe somebody has other idea or suggestion on how to repair this TDS540C

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 04, 2020, 01:30:06 pm
content: Quote from: madao on January 01, 2020, 05:56:44 amHell Matt,You're genius, stupid of me where I did mount incorrectly the digital bus connector.Today I deconstruct again the unit, solder the shorts on R1062 and R1063, mount correctly and the firmware auto-detects the standard 2G/s and removes the 1GS/s option (see attached 3 pictures).Thank you so much... now I need to find a front panel replacement and of course see how to repair if doable the Faill ++ProcessorAmicalement, Albert

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 07, 2020, 08:17:57 am
content: Here is an update where now it seems clear what board is in partial fail.As a reminder, I have two TDS540C where the healthy one has 2GS/s standard and the partial failed one 1GS/s.I've deconstructed each acquisition board then I've swapped these boards. From the attached picture, we can now verify that the FAIL ++Processor is ONLY due to acquisition board.Not sure if this can help but here is both boards with their memories chip.TDS540C-1G failedSerial B010811Processor board S/N 9740LDS1486-120 9735HDS1650Y-100 9716Uflashfile E28F016SAFirmware V5.0.1eAcquisition board S/N 9745DEEPROM X24C02TDS540C-2G workingSerial B010489Processor board S/N 9724ADS1486-120 9723HDS1650Y-100 9650Hflashfile E28F016SAFirmware V5.0eAcquisition board S/N 9810GEEPROM X24C02As a reminder, it was previously dumped the correct NVRAM content from the healthy one to the failed one but this did not solve the failure. This is why I decided to swap acquisition boards in order to estimate what sub-system is failed. This TDS540C has also one knob of its front panel partially failedhttps://www.eevblog.com/forum/repair/tds-540c-partial-failure-horizontal-scale/so I guess best to keep it for spare parts.Unless one knows exactly what is wrong on the acquisition board (i.e. X24C02 EEPROM), my understanding whatever I do with this TDS, it will have to go into a full calibration FAS which I've never done so far. Time is money so maybe best I keep this TDS540C with spare parts in case the other fails one day.On a side note, I wonder if one possible explanation is not linked to the fact the healthy TDS540C Acquisition board S/N dates 1998 even though the failed TDS540C is younger.About the NVRAMs, I'm ware these are quite old circa 1996 and 1997 implying their potted batteries might fail in the near future so I'm dumping-saving the content of these NVRAMs as well as its flashfile firmware and EEPROM just in case. There seems to be different options to secure or replace the NVRAM chip (1486 and 1650Y) so I need to study and decide what is best in the long term.Any idea, comment, suggestion... thank you in advance

author: shakalnokturn
author_rank: Super Contributor
timestamp: January 07, 2020, 12:54:43 pm
content: If I understand right you have done a cross test and narrowed the failure down to one acquisition board that will cause the same Fail ++Processor when used with both of the working processor boards?Interesting that an acquisition board should cause a processor error to show.Is the error log still throwing the same messages as in your first post?You have one working scope so you can use that to do some comparative probing.In this case I might start checking the 24C02 bus looks clean , dumping both 24C02, writing the cal data from the good board on a spare 24C02 and replacing it on the failed one just to check... Of course this leads to an uncalibrated scope.A thermal comparison of both boards could also give you some hints.

author: madao
author_rank: Frequent Contributor
timestamp: January 07, 2020, 02:03:32 pm
content: I ask you, have you checked, 2Gs/s per channel?It confirm failed 24c02.Two way to solved this problem: Replace 24C02 and run FAS (but time is money, you say it)Make a copy of good 24C02 and put it into, but o'scope is uncalibrated, because it save calibration constant.greetingsmatt

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 07, 2020, 02:11:19 pm
content: Quote from: madao on January 07, 2020, 02:03:32 pmQuote from: madao on January 07, 2020, 02:03:32 pmHow can you be sure because when I display the failed Oscope with Ch1 Ch2 Ch3 and CH4 with no input signals then try different V/div, they all seem to stay near zero ?Quote from: madao on January 07, 2020, 02:03:32 pmTime is money plus it is not sure the 24C02 is the reason, see above PLUS there are no stable EEPROM dumping-writing software about C-series.

author: madao
author_rank: Frequent Contributor
timestamp: January 07, 2020, 03:53:30 pm
content: I mean: Did you checked, did good acquisition board runs in failed TDS540C up to 2Gigasamle /s per channel? (max 2 Ch active)But you shouldn't wondering, if trace have much distortion by 2Gs/s. -> SPC, don't be worried.Trace is not on zero (only near), it is normal. You haven't started SPC.If EEPROM's or NVSRAM (DS1486)'s calibration constant is corrupt, it load with default constant. It works good with default constant, but it is uncalibrated.Check of failed Board in good unit conforms again, bad/corrupt 24C02 EEPROM. I asks you: where is other NVRAM on acquisition board? Only both 24C02.You can sending only acquisition board to me and i read good dump of my TDS754C and put into your board and check it. I will needing this works about 60 minutes. This is my proposal, because i know, you haven't programmer/flasher for flash/EEPROM.And it saves your time. Indeed, problem with uncalibrated state stays.Greetingsmatt

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 07, 2020, 05:28:34 pm
content: Quote from: madao on January 07, 2020, 03:53:30 pmYes your resistor modification to hack from 1GS/s to 2GS/s has worked very good, seehttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2856924/#msg2856924Of course this does not solve the fail ++Processor

author: madao
author_rank: Frequent Contributor
timestamp: January 07, 2020, 05:46:39 pm
content: ops, mistaking.I asked you , did good acquisition board run in TDS540C with 1G-option up to 2 Gs/s.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 07, 2020, 05:59:09 pm
content: Quote from: madao on January 07, 2020, 05:46:39 pmGood acquisition board always 2G standard wether installed on bad TDS540C or good TDS540C. It seems once R1601 R1602 and R6103 are correctly set to 2GS/s then the hardware SELF-detects and tells 2G to all TDS540C as you predicted few weeks agoSimilar to option 13, if there is RS232-Centronic board then TDS banner shows Option 13 otherwise it will not

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 08, 2020, 04:53:55 am
content: Quote from: madao on January 07, 2020, 03:53:30 pmI do not understand what you are asking here, please explain with more details ?Both NVRAM's are on processor-display board, see again my posthttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2860746/#msg2860746describing both TDS540C's

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 08, 2020, 08:30:25 am
content: Quote from: shakalnokturn on January 07, 2020, 12:54:43 pmAs explained before, I've only installed the Acquisition board from the good TDS540C into the failed TDS540C then it makes the complete Pass on the TDS540C being troubleshooted as shown in my pictures.Merci, Albert

author: madao
author_rank: Frequent Contributor
timestamp: January 08, 2020, 03:26:20 pm
content: Quote from: Tantratron on January 08, 2020, 04:53:55 amAgain ! Pleas search after nonvolatile memory on acquisition board, which it is not 24C02. You wouldn't find it. Nonvolatile memory/NVRAM on acquisition board is ONLY both 24C02. Remember pleas an error message,which kind of error message ("nv" = non volatile)

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 09, 2020, 07:09:09 am
content: Quote from: madao on January 08, 2020, 03:26:20 pmHello Matt,Clearly the official Logfile since last december always and systematically mentioned a NV failure (see many posts in tihs thread).Initially it was suggested the NVRAM's of processor board to be corrupted so I did I uploaded good 1486 bin file but this did not solve the failure.Then I've exchanged acquisition board between the two TD540C to confirm the problem comes from NV inside acquisition. If there is only EEPROM chi as unique NV memory on acquisition board, then it means X24C02 are failed.This morning I redo pictures of the failure report, see attached for details and information.Do you know in general if it is common or happen many times, why technically speaking the X24C02 tend to become corrupted ?I ask because find strange why passive electronic memory would fail unless the problem would be the software and 68K to sometimes not write or read correctly for some reason the X24C02.As for de-soldering and replacing with new X24C02, not sure to do it because it will the require to calibrate the oscilloscope which I've never done plus will cost more than look for spare parts for swapping.Best, Albert

author: shakalnokturn
author_rank: Super Contributor
timestamp: January 09, 2020, 10:50:22 am
content: From my experience with 24Cxx/93Cxx, that being none with any Tek scopes but mainly TV's and monitors, data corruption mostly seems due to power failures during writing to the device.On the odd occasion I've come across completely failed (unreadable) EEPROMS.Still at the risk of repeating myself, do try probing power at the 24C02 and checking I²C bus levels look normal.I would try duplicating the working 24C02 and moving that to the failed acquisition board, although it won't be calibrated, depending on manufacturing tolerances it may be good enough to call a working scope.If you don't have a programmer (they are a good investment) and can provide me with someone else's dump file for the 24C02, I could write one and post it to you.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 09, 2020, 01:57:28 pm
content: Quote from: shakalnokturn on January 09, 2020, 10:50:22 amThank you shakalnokturn for your return of experience regarding the power failure root-cause leading to possible fatal corruption of both 24C02's.Please make a note of specific threads dealing on updated software method using GPIB-USB interface where member ragge and madao has improved the C files of tektool, tekfwtool and maybe getcaldata. I'm using a Macintoh but other members use Linux or Windows, it does not really matter where now we can save-dump very easy the content of the NVRAM, the content of the flashfile firmware then we can write, program the NVRAM, the flashfile. I've tested, some members have as well and it works as reported in the threadhttps://www.eevblog.com/forum/repair/tekfwtool-for-tds540c-firmware-upgrade/msg2861266/#msg2861266What is left and open case concerns the possibility to dump-save then write-flash the X24C02 EEPROM where there is software updated in this repositoryhttps://github.com/ragges/tektoolsbut it is not clear if it really works. What is not clear but I might be wrong and miss the information, what is the precise memory mapping address of the X24C02 so it cab ne read or written via GPIB-USB channel.Otherwise as you know, I have a valid healthy TDS540C so could dump its X24C02 content then load into the failed one once both EEPROM would be de-soldered and replaced by new ones. There would the other topic to re-calibrate which can cost time, money and require specific equipment I need to identify along with the calibration procedure.N.B. I do not have for the moment a programmerMerci, Albert

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 10, 2020, 08:44:01 am
content: Thanks to the remark of shakalnokturn, I'm now realizing a salient point where the two EEPROM are I2C protocol linked so the reading or writing their content is serial... not parallel as the NVRAM and the flashfiles memoriesAttached an extract of the TDS520B component manual based on 68020 which might be partially correct for C and Series (to be confirmed since 68040). Maybe someone knows where in the document we can find the single address or port definition to I2C dialog with both 24X02 via the GPIB port ?Albert

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 10, 2020, 09:33:46 am
content: Hello again,I've now dumped the content via the GETCALDATA softwarehttps://github.com/ragges/tektools/tree/master/getcaldataof each EEPROM, see attached zip files containing the respective dump of the working TDS540C and the failed TDS540C... what do you think, is it possible to detect corrupted data, maybe write this data on another oscilloscope (what software...) to check if the data will fail the Processor board ?Thank you, Albert

author: shakalnokturn
author_rank: Super Contributor
timestamp: January 10, 2020, 01:44:10 pm
content: I'm no guru when it comes to this stuff.I had a quick look at your dump files with Hex Workshop, the overall data structure looks very similar on both scopes, the "1G" do lack a little detail compared to the "2G" ones, I'm not sure what I'd blame that on other than maybe less is needed due to the 1G limitation.At this point if there are no options to write to the 24C02 and considering you have backups of the data, you could consider a physical swap (desoldering) of the 24C02 from one Acq. PCB to another, at least that way you'd be sure that the 24C02 are the problem and not something else on the Acq. PCB.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 11, 2020, 06:42:43 pm
content: This afternoon, i've run a java application developed by FLYTE which detects valid or invalid checksum on NVRAM content as well the EEPROM content, please seehttps://github.com/ragges/tektools/tree/master/tdsNvramFloppyToolon edit/uptate 4Wether my healthy TDS540C dumped of EEPROM or the failed TDS540C dumped EEPROM, the java verificator states both EEPROM to be valid. As a reminder, I did dump via the GPIB and tekftool the content of each EEPROM via getcaldata applicationhttps://github.com/ragges/tektools/tree/master/getcaldataSo the NVRAM's are OK, the EEPROM seems to have correct checksum (see attached picture)... do you think the Fail ++Processor could have another root cause ?Thank you, Albert

author: madao
author_rank: Frequent Contributor
timestamp: January 12, 2020, 05:01:14 am
content: Checksum at all byte of dump ?Let me tell: Checksum covers few byte, not all. You can setting few byte into some area of NVSRAM-dump manually and it is not corrupt.I didn't have a glue, how should eeprom-dump look.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 12, 2020, 06:11:03 pm
content: It would be interesting and helpful to see if CHARLYD finally solved his Fail ++Processor where his posthttps://www.eevblog.com/forum/testgear/tds754d-fail-processor/msg1319802/#msg1319802shows the same error log as the one I'm sufferingLater CHARLYD received the new EEPROM solving part of the issuehttps://www.eevblog.com/forum/testgear/tds754d-fail-processor/msg1340838/#msg1340838but not sure of his oscilloscope was finally repaired.

author: charlyd
author_rank: Frequent Contributor
timestamp: January 13, 2020, 01:00:46 pm
content: place 2 new empty 24C02 chips U1052 and U1055 ( only 1 is filled in most cases ) but they are in a terrible place so why not swap them both at onces and take you FAS and go. after CVR_cal is finished the cpu fail should be gone. this is of course related to the TDS700 series

author: ragge
author_rank: Regular Contributor
timestamp: January 13, 2020, 01:41:23 pm
content: Quote from: charlyd on January 13, 2020, 01:00:46 pmSo you mean that the FAS actually writes to the EEPROMs, not only to the NVRAMs?I had the impression that the EEPROMs where only written to during manufacturing (or probably component level repair of the board).Ragnar

author: charlyd
author_rank: Frequent Contributor
timestamp: January 13, 2020, 08:33:16 pm
content: yep that s right of course full recal is needed.latest FW for : TDS540C,F/W,5.3and many versions listedhttps://www.eevblog.com/forum/testgear/tds754d-fail-processor/msg2869574/#msg2869574

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 14, 2020, 01:19:31 pm
content: hello,I'm still bit confused by the respective answer of Shakalnoktur, madao and Charlyd regarding how to handle the EEPROP story (reading, writing both 2X24C02) versus if it can explain my TSD540C Fail ++Processor (attached again).Something is stil not clear because some say that we can write data from previous save before corruption of the EEPROM or from another valid TDS540C into a new fresh EEPROM. Some other say it will not work and only running a full calibration FAS onto fresh EEPROM will be valid.Furthermore my understanding is that FAS will actually write at some point the data into the EEPROM so there should an option if we know the exact mapping address to actually write the EEPROM via the GPIB-USB way. We already know that getcaldata is able to dump or read the content of the EEPROM including CRC check via the GPIB-USB so why not writing as well.I know that FAS target is to fine calibrate an oscilloscope in particular if some components got replaced but it was suggested before to try replacing the EEPROM with valid data to see if the Fail ++Processor goes away. Later it has said only running FAS into fresh (never written EEPROM) will solve the issue so i'm totally confused.P.S.1. Since the FAS is run from a DOS computer to control the process via GPIB, maybe someone has designed C source file able to mimic the FAS so we could do from Windows, Linux and MacOS.P.S.2. Maybe I'm wrong but it seems the souring of X24C02 is only from China or maybe obsolete so we could have similar issue as the sourcing of NVSRAM 1486 and 1650YThank you, Albert

author: charlyd
author_rank: Frequent Contributor
timestamp: January 16, 2020, 11:09:44 pm
content: Hi i had exactly the same error your 24c02 info is already corrupt( it says: NvlibrainDiags and libs with CRCC error.)The storage 250 error is pointing to your broken 24CO2 chips. these are the onces i orderedhttps://www.ebay.com/itm/143318363050In the beginning i also tried to restore my old content which i saved with a programmer and also content from an other scope.. it all doesn t bring you anything... just solder the empty chips on your ACQ board power on the scope ..and you need a CVR-Cal.1. COLD_START (Initialization)2. SPC Signal Path Compensation3. CVR_CAL Voltage Reference4. POWER_CYCLE (Reset)9. PROBE_COMP_CAL Voltage Referenceclear your error log and boot and seethe CPU fail should be gone. After that do the HF_cal and Interleave to finish your complete Calibration.i hope this clears things up..

author: ragge
author_rank: Regular Contributor
timestamp: January 18, 2020, 04:24:48 pm
content: Quote from: charlyd on January 16, 2020, 11:09:44 pmMay I ask I there was some specific reason for buying them on Ebay, when there are new ones available much cheaper from about every electronics shop (Farnell, Mouser, Digikey, Distrelec, ...)?How do you know that the problem is with the EEPROMs, couldn't it just as well be a problem with the NVRAMs?

author: charlyd
author_rank: Frequent Contributor
timestamp: January 18, 2020, 05:37:23 pm
content: of course you may buy them where you want. I just pointed to this link and not the chinese models ;-)nope it is not the NVram only. he will see even after swapping both Dallas chips. the 250 storage error is NOT gone.

author: ragge
author_rank: Regular Contributor
timestamp: January 18, 2020, 05:45:25 pm
content: Quote from: charlyd on January 18, 2020, 05:37:23 pmSure, I just wonder why anyone would you buy them from some random source on Ebay at all when you can get factory new ones through hopefully controlled channels, and cheaper?To try make my question clearer:How can you tell that the EEPROMs and not something else are the problem?Regards,Ragnar

author: charlyd
author_rank: Frequent Contributor
timestamp: January 19, 2020, 09:38:15 am
content: @ragge : i advise to read the above posts...about the storage 250 error. the cal info is stored in these chips.

author: ragge
author_rank: Regular Contributor
timestamp: January 19, 2020, 12:17:35 pm
content: Quote from: charlyd on January 19, 2020, 09:38:15 amHi Charlyd,I have read the thread. It is still not clear to me how you can determine that the EEPROMs are broken and needs to be replaced.After all, broken 24C02:s aren't very common, not random bit flips in them either.I understand it as it is only written during FAS calibration, so it shouldn't have been corrupted while writing.They are typically specified for 60-100 years, but some may be worse of course.The 24C02:s can seemingly can be read so they don't seem entirely broken. The data can be verified by checksumming, but maybe there still is a problem with data that isn't checksummed.- The error codes indicate NVRAM problems, and several have suggested that it can be in the other NVRAMs as well. Though, the board swap shows that the problem follows the acquisition board, so probably not.- As others have suggested, it may be some other problem with the I2C bus, maybe some other device on the same bus, if there are any.You may absolutely be right, I just wonder how you got to your conclusion that the EEPROMs must be replaced.Regarding where to buy the EEPROMs - so there is no reason not to buy them through the normal electronics suppliers (Farnell, Arrow, Mouser, Digikey, Distrelec ...)?

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 21, 2020, 10:56:03 am
content: Hello All, this morning I've decided to make some new dumping - reading test of each EEPROM. As a reminder, I have two TDS540C where one is healthy and other partially failed.Now I've dumped the EEPROM content via two methods (1) FloppyDisk EXE application and (2) getCalData through GPIB. Normally if both applications are OK, the BIN files should be the same.See attached the ZIP compress hosting the 4 dumpings: 2 dumps for TDS540C-2G (healthy) and 2 dumps for TDS540C-1G (failed).For some mysterious reason, the 2 dumps of healthy TDS are exactly the same which means wether Floppy Disk utility to read EEPROM content or the GetCalData (C source file compiled) reading EEPROM via GPIB-USB interface, the 24C02 chips have the same content.However the failed dumps show an extraordinary BIN file content difference... why no idea but now I wonder if the failure is not due to some bus linking the EEPROM to the Display Processor. What are the different protocols or addressing mode when reading the EEPROM via GPIB control versus reading via FloppyDiskThank you, Albert

author: shakalnokturn
author_rank: Super Contributor
timestamp: January 21, 2020, 04:27:41 pm
content: Does the floppy dump utility check data as it writes it? After looking at your files I'd easily blame that on floppy data errors... Have you tried more than one write on different disks?If I'm wrong about the floppy and you have more time to spend swapping things around, it would be nice to see the same 4 backups made once you have crossed the acquisition boards.

author: ragge
author_rank: Regular Contributor
timestamp: January 21, 2020, 10:59:09 pm
content: Quote from: shakalnokturn on January 21, 2020, 04:27:41 pmI think I can answer this:No, it doesn't check the write. The script is this:https://github.com/ragges/tektools/blob/master/tdsNvramFloppyTool/tdsAcqEEPROMFloppyDumper/acqedump.app(or this, which also dumps the NVRAM at the same time:https://github.com/ragges/tektools/blob/master/tdsNvramFloppyTool/tdsNvramEepromFloppyDumper/dumpall.app)It can absolutely be a floppy problem - I too would recommend trying again, preferable even with another floppy, and see if you get the same result or not.The 1G file from "getcaldata" has much more repeated values than the 2G file.If the firmware can't read the EEPROM, will it make up default values?getcaldata reads two bytes at a time using the command "WORDCONSTANT:ATOFFSET? 262144,N", where N is 0 ... 251.Would it maybe be possible to write the EEPROM using some other "WORDCONSTANT:" operator?Edit: Partly answering my own question:There is a "WORDCONSTANT:ATOFFSET A,N,X" command that one could guess would set data.There also is "CALIBRATE:STORE?" that may or may not be interesting.Does anyone know if these could be used to store data to the EEPROM, and if so how, and if "262144,N" where N is 0 ... 251 is the right way of accessing the data, or if there are other values/addresses/indexes/whatever-they-are that should be used?Ragnar

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 22, 2020, 08:02:09 am
content: Quote from: ragge on January 21, 2020, 10:59:09 pmHello ShakalNokturn and Ragnar,Please find attached a new run done this morning on the failed TDS540C, here i've dumped both EEPROM and NVRAMs via 2 methods (floppy disk driver and GPIB).Kindly note that I only have one floppy disk (old tektronix 1.44Meg disk which came when I purchased on eBay the healthy TDS540C). Maybe you're right that my floppy disk driver is failed or it would be good to try another floppy disk... no idea but if you display all the BIN files attached, you'll notice that during the All-Dump using my floppy disk and floppy driver the NVRAM content are exactly the same wether done by GPIB or Floppy. Since the Floppy dump method did extract both EEPROM and NVRAM (check screen picture) I conclude that maybe the floppy are OK.If you have some spare floppy disk maybe you could send me one to my physical address in France. However as mentioned before when I did dump both EEPROM and NVRAM on my healthy TDS540C, all files did match when compared to GPIB dumping.If for some reason we conclude the floppy disk and floppy driver are OK on both my TDS540C then it brings a serious technical topic to understand why there is failure when dumping EEPROM via Floppy whereas if dumping EEPROM via GPIB it works including correct checksum. This would imply that there are different internal addressing mode (read or write) the EEPROM from the Processor board or Acquisition board. Bad luck would be that when self-test on boot, the TDS540C does attempt reading the EEPROM and fails as does the Floppy. So maybe the EEPROM is valid, no need to solder new ones but this poses the troubleshooting method to apply.Quote from: shakalnokturn on January 21, 2020, 04:27:41 pmIf there is serious interest of some members, I might spend some extra time later this week or week-end to actually swap both acquisition board then specifically run the healthy TDS540C connected to the suspect un-healthy Acquisition board. I'd of course re-dump all files via Floppy and GPIB to see if the EEPROM content is visible and not corrupted.Albert

author: ragge
author_rank: Regular Contributor
timestamp: January 22, 2020, 01:53:17 pm
content: Quote from: Tantratron on January 22, 2020, 08:02:09 amThis time the floppy dump only contain zeroes, while the GPIB dump is the same as the previous one.To hexdump the files, you can for example use:hexdump file.binod -Ax -tx1 file.bin# the flags make the output be all in hex bytewiseTo compare files you can use for example:diff -uw file1.bin file2.bincmp file1.bin file2.binQuote from: Tantratron on January 22, 2020, 08:02:09 amIf you get an (undetected) floppy error, it could potentially be on just a single bit, but typically on more.If you had got the same result with both methods, it would be a good indication that the methods worked, but now you didn't, and then it is a good idea to try to determine where the error got injected.Quote from: Tantratron on January 22, 2020, 08:02:09 amNote that you can get a floppy data error on a otherwise totally working floppy drive and floppy disk - that they have worked before is no guarantee.Yes, the two program use different methods of accessing the data.Looking at them, it to me seems likely, but Idon't know, that the getcaldata is reading from the copy in RAM, while tdsNvramFloppyTool reads directly from the EEPROMs.Itcould bethat if the scope can't read the EEPROMs when it boots, it will make up a default calibration data set and put in RAM.Since you got different results, I would try it even more, or maybe make your own scripts that dumps it five times two five different files in one boot.Based on what we currently know, there seems to be a problem with reading the EEPROM. It could be broken EEPROM(s), which others say they have had, or some other problem.You could try replacing the EEPROMs (10-60 cent each for new ones), but you would have to program them too.Since the old calibration data seemingly can't be reached anymore, my suggestion would to fill them with the data that you currently can read out using GPIB.But then you haven't really gained anything more than removing the error message.Another option would be to replace them with empty ones and find someone with all the equipment to run a full calibration using FAS - maybe you have it at the lab.If you take out the old ones and succeed to read them with something else, the problem probably isn't with the EEPROMs themselves. You then could try new ones with the data from the old ones, and if it still doesn't work, there must be some other problem on the I2C bus.Or, if it actually is the case that it is now running with a default calibration (which we don't know but seems likely), you could settle with that and ignore the error message. One problem with that is that it may not be as obvious if more errors develop.Ragnar

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 22, 2020, 02:15:30 pm
content: N.B. Last night I did different EEPROM dumps with Floppy on 2G healthy and 1G failed TDS540's, see attached where the 2G always generates the same EEPROM binary file. However on the 1G, there are different failed dump which can be attributed either to failed Floppy driver installed on 1G or something else on the acquisition board. Since the floppy disk is the same wether I read 2G scope or 1G scope, I'd tend to conclude the disk is OK.On a side note, the DOS application ACQUEDUMP in charge of EEPROM dump seems to useinternalGPIB link, seeCode:nulldev = open("/null",3,0666)taskSpawn "Redirect",1,0,0x4000,ioGlobalStdSet,1,nulldevtaskDelay (600)GpibInput("WAITICON OPEN")GpibInput("mess:box 80,80,450,200")GpibInput("mess:show \"\n\n\n\n ACQ EEPROM dump to floppy started, please wait.\"")acqEEPROMSize=0x200tempBuf=malloc(acqEEPROMSize)_gtlX24c02Bcopy(0x10A00000,tempBuf,acqEEPROMSize)ls "fd0:/"fd=open("fd0:/acqeeprm.bin",0x0202,0777)bytesWritten=write(fd,tempBuf,acqEEPROMSize)close(fd)confmsg=malloc(500)sprintf(confmsg, "mess:show \"\n\n\n\n Dump completed, power off instrument.\n\n")sprintf(confmsg+strlen(confmsg), " Bytes requested: %d \n Bytes written to disk: %d \n\"", acqEEPROMSize, bytesWritten)GpibInput(confmsg)GpibInput("WAITICON CLOSE")GpibInput("bel")This code calls_gtlX24c02Bcopysubroutine which can be precisely found inside the firmware when doing a TEXT searchHowever the getcaldata source code does use another method from theexternalGPIB interface, seeCode:/***CAL EEPROM backup - for TDS520B,TDS540B,TDS724A,TDS744A,TDS754A,TDS782A,TDS784A**compiled with MinGW gcc on Windows Vista / Win7* tested with Agilent I/O 16.x and S82357 from http://bmjd.biz/index.php***/#include <stdio.h>#include <stdlib.h>#include <string.h>#include <errno.h>#if defined(WIN32) || defined(_WIN32) || defined(__WIN32__) || defined(__NT__)#include <conio.h>#include <windows.h>/* for NI adapters uncomment following line *//* for Agilent adapters uncomment following line */#include "ni488.h"#elif defined(__linux__)/* linux with linux-gpib */#include <gpib/ib.h>#elif defined(__APPLE__)/* MacOS with NI GPIB drivers */#include <ni4882.h>#else#error "Unknown compiler environment!"#endif#if !defined (PROG_NAME)#define PROG_NAME __FILE__#endif#if !defined (GIT_VERSION)#define GIT_VERSION "unknown"#endif#if !defined (BUILD_TIME)#define BUILD_TIME __DATE__ " " __TIME__#endif#define ARRAYSIZE 100 // Size of read bufferint Dev; // Device handlechar ReadBuffer[ARRAYSIZE + 1]; // Read data bufferchar ErrorMnemonic = {"EDVR", "ECIC", "ENOL", "EADR", "EARG","ESAC", "EABO", "ENEB", "EDMA", "","EOIP", "ECAP", "EFSO", "", "EBUS","ESTB", "ESRQ", "", "", "", "ETAB"};void GPIBCleanup(int Dev, char* ErrorMsg);static int debug;static char* ident = PROG_NAME " Version: " GIT_VERSION " Build time: " BUILD_TIME;static void print_version(void){fprintf(stderr, "# %s\n", ident);}int main(void) {/** ========================================================================** INITIALIZATION SECTION** ========================================================================*//** Assign a unique identifier to the device and store in the variable* Dev. If the ERR bit is set in ibsta, call GPIBCleanup with an* error message. Otherwise, the device handle, Dev, is returned and* is used in all subsequent calls to the device.*/#define BDINDEX 0 // Board Index#define PRIMARY_ADDR_OF_DMM 1 // Primary address of device#define NO_SECONDARY_ADDR 0 // Secondary address of device#define TIMEOUT T10s // Timeout value = 10 seconds#define EOTMODE 1 // Enable the END message#define EOSMODE 0 // Disable the EOS modeFILE *outfile;int f;#if 0unsigned long addr;// addr = 0x00040000L; /* CAL data base address on TDS5xxB,6xxA,7xxA*/addr = 262144; /* CAL data base address on TDS5xxB,6xxA,7xxA*/#endifprint_version();Dev = ibdev (BDINDEX, PRIMARY_ADDR_OF_DMM, NO_SECONDARY_ADDR,TIMEOUT, EOTMODE, EOSMODE);if (ibsta & ERR){GPIBCleanup(Dev, "Unable to open device");return 1;}/** Clear the internal or device functions of the device. If the error* bit ERR is set in ibsta, call GPIBCleanup with an error message.*/ibclr (Dev);if (ibsta & ERR){GPIBCleanup(Dev, "Unable to clear device");return 1;}/** ========================================================================** MAIN BODY SECTION** In this application, the Main Body communicates with the instrument* by writing a command to it and reading its response.** ========================================================================*/ibwrt (Dev, "*IDN?", 5L);if (ibsta & ERR){GPIBCleanup(Dev, "Unable to write to device");return 1;}ibrd (Dev, ReadBuffer, ARRAYSIZE);if (ibsta & ERR){GPIBCleanup(Dev, "Unable to read data from device");return 1;}ReadBuffer = '\0';printf("DSO IDN: %s\n", ReadBuffer);outfile = fopen("U1052.bin","wb");printf("dumping U1052.bin\n");printf("\nPlease wait ...\n");/* the first 8 bytes of the U1052 EEPROM are not mapped and empty (0x00h)so we write as well 8 time 0x00h to dump file */for(f = 0; f < 8; f++){fputc(0x00, outfile);}/* send first TEKTRONIX Password fr TDS5xxB/7xxA models to allow memory dump */ibwrt (Dev, "PASSWORD PITBULL", 17L);if (ibsta & ERR){GPIBCleanup(Dev, "Unable to write to device");return 1;}unsigned char calbuf;int caldata;for(f = 0; f < 124; f++){char cmdbuf = "WORDCONSTANT:ATOFFSET? 262144,";char cmdnr;sprintf(cmdnr,"%d",f);strcat(cmdbuf, cmdnr);if (debug > 1) printf("DSO IDN: %s\n", cmdbuf);ibwrt (Dev, cmdbuf, sizeof(cmdbuf));if (ibsta & ERR){GPIBCleanup(Dev, "Unable to write to device");return 1;}ibrd(Dev, calbuf, 6);if (ibsta & ERR){GPIBCleanup(Dev, "Unable to write to device");return 1;}caldata = atoi((char *) calbuf);if (debug > 1) printf("CAL DATA: %X\n", caldata);unsigned char* abuffer = (unsigned char *)&caldata;fputc(abuffer, outfile);fputc(abuffer, outfile);}fclose(outfile);outfile = fopen("U1055.bin","wb");printf("dumping U1055.bin\n");printf("\nPlease wait ...\n");for(f = 0; f < 128; f++){char cmdbuf = "WORDCONSTANT:ATOFFSET? 262144,";char cmdnr;sprintf(cmdnr,"%d",f+124);strcat(cmdbuf, cmdnr);if (debug > 1) printf("DSO IDN: %s\n", cmdbuf);ibwrt (Dev, cmdbuf, sizeof(cmdbuf));if (ibsta & ERR){GPIBCleanup(Dev, "Unable to write to device");return 1;}ibrd(Dev, calbuf, 6);if (ibsta & ERR){GPIBCleanup(Dev, "Unable to write to device");return 1;}caldata = atoi((char *) calbuf);if (debug > 1) printf("CAL DATA: %X\n", caldata);unsigned char* abuffer = (unsigned char *)&caldata;fputc(abuffer, outfile);fputc(abuffer, outfile);}fclose(outfile);printf("\nCalibration data has been successful dumped\n");/** ========================================================================** CLEANUP SECTION** ========================================================================*//* Take the device offline. */ibonl (Dev, 0);return 0;}/** After each GPIB call, the application checks whether the call* succeeded. If an NI-488.2 call fails, the GPIB driver sets the* corresponding bit in the global status variable. If the call* failed, this procedure prints an error message, takes the* device offline and exits.*/void GPIBCleanup(int ud, char* ErrorMsg){printf("Error : %s\nibsta = 0x%x iberr = %d (%s)\n",ErrorMsg, ibsta, iberr, ErrorMnemonic);if (ud != -1){printf("Cleanup: Taking device offline\n");ibonl (ud, 0);}}So for sure there are two software and probably hardware method to READ the EEPROM where for some reason, one fails possibly explaining the FAIL of the oscilloscope

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 22, 2020, 02:29:52 pm
content: Quote from: ragge on January 22, 2020, 01:53:17 pmPlease remember that the time-labour to deconstruct, de-solder then re-solder 60 cents EEPROMs then time to run FAS is exponential. It is still not proven the EEPROM to be corrupted so yes new ones cost less than 1 euros but all the effort (solder, program, calibrate) is disproportionate. I do have some calibration tools in my lab like the PG506 necessary for voltage cal but not all test equipment where in the past I only repair, calibration 24xx tektronix oscilloscope.My gut feeling suspects that GPIB management of EEPROM, firmware and NVRAM to be more stable and safe compared to using floppy disk. However the problem here is to understand the root cause of the Fail ++Processor where I'm still lucky to have a 2nd TDS540C which runs fine.Albert

author: ragge
author_rank: Regular Contributor
timestamp: January 22, 2020, 03:50:20 pm
content: Quote from: Tantratron on January 22, 2020, 02:29:52 pmI fully agree.But if you care about the cost for the time, you should not do this at all - you can buy a working 540C on Ebay for Euro 500 or so, you have already spent much ore than that on this scope. I do this since it may help fixing more scopes, including my own, in the future, and because I like to understand how my gear actually works.Note, again: That the floppy method has worked before is NO guarantee that it will work without errors again, so you could try it again, though I too suspect that is not the problem here since you have already tried it twice.One other method could be: Hooking up on the I2C bus with some other I2C bus master device and try to read the EEPROMs that way. You need to have power to the EEPROM:s, so the easiest way would probably be to do it with the scope running and first making sure nothing else uses the I2C bus, since that would garble the data for both you and the other bus master.You could also check the signals on the I2C bus with a scope and see if they at least look OK.With my current knowledge of these things, I can't think don't know of anything more to try really.So, as I wrote in my previous message, I would either.- just live with the error message, convince yourself that it runs with default calibration, maybe compare performance to some other scope, and see of some better ideas show up- try reading them in place with something else as suggested above- take the old ones out and see if they for some strange reason can be read outside of the scope. Then there probably is some other problem, with the I2C bus or the power or something else.- put new ones in either with the default data (and convince yourself that this is what you currently get with getcaldata), with the data you got from the ones you removed if there is any, with the data from the working one (which would be worse than a default set), or empty and run a full FAS.Ragnar

author: charlyd
author_rank: Frequent Contributor
timestamp: January 22, 2020, 07:43:22 pm
content: what does the errorlog say? console port? mostly the clue can be found there:something like this:[my old log part]nvLibrariansDiag ............... ***FAIL***..error details:ERRORID: 163 diagnostic test failure nvLibrariansDiagLibs with crcc failures:ExtConstwhat do your cals say: VOLTAGE / FREQ / … show..PASS or INITIALISE?

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 23, 2020, 08:43:44 am
content: This morning I decide to do the suggestion of Shakalnokturn, namely deconstruct both TDS540C's acquisition board then install the failed Acq board into the healthy 2G . So I've kept all subsystems of the healthy TDAS-540C-2G except installing the Acq board taken out from the failed TDS540C-1G.Please find attached different files where I've GPIB cleared initially the LOG error file so it will show the first error after installing the Acquisition board. Unfortunately we can see that now the healthy TDS540C will indicate FAIL ++ Processor as well as same Error Log content and the SPC will get stuck on INITIALIZED... totally the same situation as beforeI've also dumped via GetCalData the content of the EEPROM via GPIB which seems to be HEX same as when dumped from the failed TDS540C few days ago.On a side note, the only single floppy disk which worked fine with the failed TDS540C cannot work anymore for some reason. The TDS540C will format it OK then I copy from my Mac the AcqDump DOS routine but will never boot in theTDS540C. As a reminder the very similar process successfully worked on the failed TDS540C. For the moment I cannot dump the EEPROM via the Floppy from my working TDS540C whereas few days ago it was working !!!Anyway the point after installing the failed Acq Board into a healthy TDS540C shows same failure. In order to eventually help members or google search, I'll type in this post the exact Error Log contentDiagnostic LogFAIL ++ Processorpass -- Cal Initialization (see error log)Error LogFATAL: 250 nv storage too small more bytes requested than availableERROR: diagnostic test failure nvLibrariansDiag, Libs with crcc failures: , ExtConstFATAL: 250 nv storage too small more bytes requested than availableERROR: diagnostic test failure extended cal librarian resetIt seems like the main FATAL issue is not enough bytes to read or write on 250 nvKey question: who is 250 Non Volatile memory component ?

author: charlyd
author_rank: Frequent Contributor
timestamp: January 24, 2020, 07:02:42 pm
content: the cals as shown in the last picture only gets solved with calibration. I had the same call s pictures posted here on the forum ..my SPC also worked fine. The Voltage you can do seperate to see if you cpu fail is gone. i explained already abovebut first you need to solve:250 nv storage too small more bytes requested than availableand as i said above thisdiagnostic test failure nvLibrariansDiag, Libs with crcc failures: , ExtConst-point to the 24CO2 chipsWhile calibrating info is written and stored in there and guess what they have CRCC failures.Of course you can check the power rail and the I2C to the chips but they are on a weird place for debugging.After i replaced them with new empty onces250 nv storage too small more bytes requested than availablewas gone in the errorlogwhat i don t understand is you swapped the ACQ boards out or what did you do...?? do you have the same boards? do both unit the same serial series..?you swapped the dallas chips on the cpu boards already i assume. 1486 and 1650.you dont have a console port ? to debug the scope.this is all the info i have for you.did you see my post:https://www.eevblog.com/forum/testgear/tds754d-fail-processor/

author: flyte
author_rank: Regular Contributor
timestamp: January 24, 2020, 10:44:18 pm
content: Hi all,Forum member @ragge pointed me to this thread. I originally created those floppy backup scripts.Here is the original post:https://www.eevblog.com/forum/testgear/tektronix-tds500600700-nvram-floppy-dump-tool/I will attempt to end this miseryI didn't have the time to read everything in detail, but one thing which a lot users still seem to ignore is thatthe dump tools also include a checksum verifier tool TDSNvrCV_2_0.zipwritten in Java which checks both the NVRAM and EEPROM dump files. It's there for reason! So you shouldn't guess whether the dump taken is garbage or not. So please use it. It computes the (way too) simple checksums Tektronix has put on the contents inside and verifies them. It attempts to make an educated guess regarding a (base) firmware level which the given dump is likely originating from or compatible with.There is one important thing to mention however: the tool may report valid checksums if the checksum result is 0x00 and the whole dump accidentally matches or has zeroes in it.I did not exclude this possibility from the tool, as 0x00 could really be a valid checksum result. So in case of checksum VALID and 0x00 checksum result, you have to look into the file and judge whether it could be a valid case or rather not because it's plenty of zeroes.Comparing binary data may give an indication but especially for NVRAMs it's rather a waste of time as their contents continuously change during normal operation.It's entirely possible some outputs of the floppy dump can occasionally be corrupt, especially using the dumper with the message box. Also, you will get corrupted dumps if you connect a GPIB or console interface to the scope.As pointed out in the original thread, you have to take the floppy dump with the scope minimally disturbed: no connections, no triggering, don't press buttons.It seems having to do with how the VxWorks OS executes the script vs. other tasks and interfering interrupts. I don't know more either, we have to accept it I guess. Older firmware seems more prone to these failures as well. The tdsMinimalXXX scripts seem to be the safest method in case of doubt, probably because there is virtually no interaction with the GUI.The floppy script uses the function call _gtlX24c02Bcopy which directly accesses the EEPROM in hardware. The GPIB tool, so it seems from the code, is invoking library code which then takes values from the RAM location where the same data resides. At startup, the scope copies data from the EEPROM into RAM and then uses it.However, before the EEPROM is read, this section gets initialized with firmware default values. In case afterwards things somehow fail or get skipped at boot time, you will grab those default values using the GPIB tool.In a similar fashion, if things fail and the function call _gtlX24c02Bcopy somehow aborts or doesn't exist in the given firmware, the RAM buffer the script temporarily allocates will contain garbage and will as such be written to disk.That's for the general case.Now, I will only take into consideration your first posting of dumps ACQEEPRM-Floppy.BIN and EEPROM-GPIB.bin. After that dumps seemed to be all over the place and I'm not sure you are looking at the root cause or rather side-effects of further attempts to diagnose the problem. The dump ACQEEPRM-Floppy.BIN has zeroes in it, the EEPROM-GPIB.bin dump is valid. However, inspecting that last dump and keeping in mind the above, it seems you grabbed the default values via GPIB. Beware, these aren't working defaults for the scope, it's more like a preformat the firmware can live with, ready to be set at factory production time. Your scope can't operate with them.In summary, you have some hardware problem related to the EEPROMs which you should fix. I can't see anything wrong with both tools and there is an explanation for your observations.Could be a loose contact, could be a bad EEPROM, could be worse like a bad ASIC. Maybe attempt to read the EEPROM contents using a programmer, maybe you can still get something out of it. It's very important to try this wrt. the calibration data, most of which is set a factory time and never changes. If it's lost, it's lost. Your only chance is then to load another EEPROM dump into it and hope the scope calibration values more or less match.So far I haven't discovered a way to write EEPROM data back into the EEPROM. I'm not sure it even exists in the firmware, but I suspect it does. It's unlikely I will invest time into this, as failed acquisition EEPROMs are not common and, once you have a good dump, they are easily restored by desoldering them and programming them externally.Another thing which is puzzling, is the fact there are two EEPROMs and one is always empty. Firmware can't even access the second one, so it seems. So this is either a backup EEPROM set by some unknown function, either at design time they estimated more space was needed and eventually never used it.EDIT: sorry, I just realized the EEPROMs have always been 24c02's and not 24c04's, as I somehow thought they were in some modelsIt's even in the function call's name, I must have been really distracted the day I remembered that wrong!So data is simply split across them of course!-- flyte

author: flyte
author_rank: Regular Contributor
timestamp: January 25, 2020, 09:36:29 pm
content: Ok, it happened quicker than expected, TDS scripts have been improved and can now also write the acquisition EEPROMs. Thanks to @ragge for his superb guess regarding the (ab)use of the function call !Original post:https://www.eevblog.com/forum/testgear/tektronix-tds500600700-nvram-floppy-dump-tool/Note to the topic starter: if you care about the calibration values of your scope, make sure you attempt to read them from the EEPROMs before trying to write them, whichever the effort required, including desoldering them and reading externally. You may loose values critical to your particular scope which perhaps even cannot be set back by the Tektronix service centers, as it may have been entered at the factory only. Loading a dump from a different device without having the original backup will make the scope "work" for sure, but it might never attain its former performance again. Note that it's possible you are facing other hardware problems which render EEPROM access impossible for some reason, and the EEPROMs/data could actually still be good.

author: charlyd
author_rank: Frequent Contributor
timestamp: January 26, 2020, 05:10:51 pm
content: @Flyte: i replaced them with new -never filled- empty onces and after that calibrated the scope works perfect.Why did i replace them? Because my cpu error was generated somewhere in the past, which brought me to replacing them. Maybe calibrate is just enough but the error is related to...it took me a long time to fix the cpu error, nobody ever had this, not in yahoo groups, not on tek forum, but i made progression after playing arround with the content which jwalling gave me.Of course assuming it is the same cpu fail ++ error i gave Tantratron the tip to read out with console port to get more info that he has now.

author: flyte
author_rank: Regular Contributor
timestamp: January 26, 2020, 09:52:32 pm
content: Quote from: charlyd on January 26, 2020, 05:10:51 pmOkay, but you calibrated it afterwards, that's a really big difference compared to empty EEPROMs, lost values, plain defaults or a dump from a different unit. Most people won't have the capability to calibrate scopes, and even if you have, a calibration is only as good as your calibration equipment itself, which is likely not the same a calibration lab has, unless you're into the business of operating one of course. In addition, the price of a full calibration may rapidly exceed the value of a budget second hand scope.It indeed may be the case the differences are small and perhaps also beyond your measuring capabilities or you're just lucky your scope is close to the default/average values, but I can confirm there are values contained in the EEPROM which are not altered by the calibration software. So they must have been set at factory production time and are for the life of the scope. I suspect it's more about parameters in relation to e.g. the specifics of maybe the ASIC batches, etc. Another fact is then one scope is not equal to another one. Calibration of a TDS794D or a TDS694C requires different internal specifics and precision than say a plain TDS520B or the likes. Your observation is certainly reassuring to read, but I wouldn't bet on it there is no difference at all with factory calibrated models which still have their original EEPROM cal data, and even less so it would be valid for any type of TDS5/6/7xx scope.When the EEPROMs fail or do not contain calibration data, or corrupt data, the logged error is indeed CPU FAIL. It's just an error classification, CPU FAIL can mean lots of other things as well. The error log will tell you more about the specifics. In any case, if you see "ExtCal" errors, this means it has to do with the cal data in the EEPROMs, but only if it's the later series like -B/-C/-D types. If you have -A series without EEPROMs, "ExtCal" errors would point to an NVRAM failure as everything is stored in there.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 27, 2020, 09:59:44 am
content: Hello and sorry for not answering before some of you who are really helping me. A particular thanks to @madao @ragge @flyte and @charlyd where on a side note it EXCELLENT news that @flyte with @ragge have cracked some more stuff so we can Floppy-write the two EEPROMs on the acquisition board.I've been thinking, analyzing, pondering on different suggestions wether from this thread or private PM with @madao @ragge and @charlyd along with new tests done last week and early this morning. As a reminder, I'm using the floppy-dump method of @flyte and the GPIB-USB getCalData method of @sven where for clarity, the complete set of applications are found inside the github repository of @ragge found herehttps://github.com/ragges/tektoolsUnless i'm wrong, any heathy TDS540C should provide the same EEPROM content once dumped via Floppy method of @Flyte or dumped by GPIB-GetCalData of @sven. This was confirmed with my healthy TDS540C-2G prior the swapping of the Acquisition boards, let's say Acq-1G is the failed board and the Acq-2G is the healthy board.Last january 23rd, I did swap each acquisition boards since I've two TDS540C's, one referred as TDS540C-2G is fully healthy and another referred as TDS540C-1G is partially failed in need of repair. From what I understand of detailed explanations from @flyte earlier in this thread, if for some reasons the CPU cannot read or confirm the checksum of EEPROM, it will use as default file inside the firmware for Calibration data. Once I've installed the Acq-1G inside the TDS540C-2G there is of course the Fail ++Processor, I cannot read the EEPROM from Floppy and the GetCalData-GPIB does dump a EEPROM view which is precisely the content inside the firmware (please see attached screenshot where I've found the local storage of default EEPROM inside the firmware)... so far so good. I also attach a view of both GetCalData dumps where the 2G is from the valid EEPROM, valid TDS540C before swapping.However I feel we cannot conclude the EPPROM-1G to be the only failed component in the TDS540C-1G for different reasons after swapping and performing different tests.Reason 1: we could have a situation where either the tektronix Hybrid ADG308 (U1050) in charge of the I2C communication between system and both EEPROM to be partially failed or a soldering issue.Reason 2: besides the Acq-1G board issue, I start to believe that maybe the processor-1G board is also partially failed. For some mysterious reason once swapping the Acq-2G inside the TDS540C-1G, good news is complete PASS at start, the SPC pass all tests.BUT there is a BUT... the Floppy dump of EEPROM works BUT theGPIB-GetCalData only dumps a file full of ZEROS for the EEPROM.Normally there should be no reason why the TDS540C-1G if healthy processor board to not be able to properly dump the EEPROM content of healthy Acq-2G via two methods: Floppy-dump and GPIB-dump. Furthermore what is quite strange or driving me crazy, I've dumped and checked the firmware zoning of the TDS540C-1G, it is the same as the TDS540C-2G. hence for some reason, the TDS540C-1G Processor board locally getCalData dumps a EEPROM content full of ZERO which would pass the checksum CRC check declaring the scope to system-pass.Hoping it is clear because not easy to explain by mail but my feeling: it is confirmed the EEPROM-1G are bad but rather an issue of bus communication between the processor-board and the acquisition board.I'll wait for your comments, suggestions before re-swapping the Acq-boards to recover my initial condition, namely a healthy TDS540C-2G and a failed TDS540C-1G.On a side note, I'm trying to find an RS232-USB interface with drivers to connect the TDS540C to my Macintosh, idea being to run Terminal mode to check detailed test information as suggested by @charlyd. This way more info will manifest compared to the Error Log file being kind of synthetic. If some of you know good RS232-USB cable Option 13 with drivers compatible with MacOS, I'm interested to buy such. My understanding from other threads being that the RS232 should be mapped electrically to J40 (special connector needed) or J37 or J3 all found on processor board.Thanks, Albert

author: shakalnokturn
author_rank: Super Contributor
timestamp: January 27, 2020, 11:58:24 am
content: While I respect your perseverence to try to get to the bottom of this with software only, not being that good at it myself, there are some cases where you can actually gain time by using a soldering iron and a probe.A system such as the one you are trying to debug is both software and hardware, both are interlinked, it seems a shame to not at least do some basic hardware checks when you have the necessary tools at hand.Keep it up, I'm actually learning a lot from this topic.

author: flyte
author_rank: Regular Contributor
timestamp: January 27, 2020, 01:35:34 pm
content: Quote from: shakalnokturn on January 27, 2020, 11:58:24 amCouldn't agree more. Don't get me wrong, but there is no longer a point here in drawing all sorts of conclusions from logical and functional swaps, as the parts you're swapping with could themselves be part of the defect. Your measurement tools are also biased for the same reason, as you measure via the same parts: the GPIB tools read via a shadow space, maybe intialized, maybe not, maybe subject to problems, the floppy read method is a direct hardware read but it still relies on a functional bus, the attached ASIC and correct CPU/RAM/OS operation, so it is biased too. You are attempting to diagnose by means of intersection and exclusion, but there are too many variables at play here.If you were attempting to remotely diagnose a spacecraft, I would fully agree you must lay out all possible observations and only draw conclusions from them. But this isn't electronics in outer space, we're just considering two common 8-pin EEPROMs in front of you, theactualcontents of which is still unknown at this point and perhaps masked by some other defects. Grab any soldering iron or heat gun and your preferred homebrew I2C reader, get them out, and you're done and you know for sure.However, whether or not the CPU boards are good should be fairly easy to discover, as you have a fully good and working acquisition board you say. So both CPU boards should give same operational results and the same EEPROM reading results when loaded with the same firmware and same NVRAM contents, when attached to this good acquisition board, provided it is really good and fully functional of course and you didn't miss anything there. You have all tools to do this, if you didn't already do so. Before writing anything to the NVRAM, make backups and label them and label your boards.EDIT: To draw valid conclusions, you should consider swapping only the CPU boards in the complete good unit, as even the connection cables and interconnection PCB may be the cause of a defect in the bad unit!Once you confirm the above, there's only one conclusion left, and that is there is nothing else at play but a bad acquisition board. It could then be as simple as bad EEPROM contents which needs a rewrite, or more complex like a bus or ASIC problem.The point however which you seem to be sort of missing here, is that there is a chance you could somehow ruin valuable calibration data inside those EEPROMs, by attempting to execute a write on them using potentially defective hardware. Perhaps the EEPROMs are bad, perhaps not and they contain valid cal data, perhaps they have been erased. You simply can't know using the diagnostic methods you are currently considering.

author: flyte
author_rank: Regular Contributor
timestamp: January 27, 2020, 02:28:17 pm
content: In addition to my previous post:If you anyhow want to proceed with your current non-invasive diagnostic method only - after all, it's your scope and your decision - then there is not much else you can do but to simply fire up the EEPROM writing script using a good EEPROM dump right away and hope it restores the scope to its former glory.But no complaints then if it didn't fix it and it's a hardware problem after all, or worse, that the scope would also be way off and you would have lost your original calibration data forever. Meanwhile quite some people here have shared and expressed the same concern.Admittedly, there is a nice chance those EEPROMs do in fact contain all zeros indeed and it's simply a reprogramming job, but I would never risk to make that assumption at this point without having read the actual values from them externally, certainly knowing the effort is small.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 27, 2020, 03:19:38 pm
content: Quote from: flyte on January 27, 2020, 02:28:17 pmThe reason I'm still hesitating to desolder both EEPROM then check their internal content by another means (i.e. arduino style) is quite simple. As it has been warned by many members including yourself, the philosopher stone or the core heart data of these scopes lies in the calibration content of these EEPROM. One false move like to much heat to desolder or writing wrong data then I'll loose for ever the knowledge of the factory calibration of that specific acquisition board. I've never said to not do it with my heat gun... just I'm cautious plus I've the chance to have a full working operational TDS540C to swap some sub-systems then investigate in non-intrusive manner.Just as an update, I've now removed the swapped Acq-board then installed the good Acquisition board inside the good TDS540C. As for the bad Acq-board, I've inspect it for bad PCB traces, checked some continuities per the schematics, so far so good. Later i'll try inspect visually how to recover via through holes lines the critical pins (SDA, SCL, WC) from the top side. The idea will be to probe these 3 signals once i'll install later the failed Acq-board inside the failed TDS540C.Ok now about the good TDS540C with good Processor board and good Acquisition board, back to the start where it works like a charm. So I did use again the Floppy-read script to dump the EEPROM then run the GPIB-getCalData application to dump the EEPROM again. As mentioned before both BIN files match together AND are slightly different that the default EEPROM content saved inside the firmware. So the TDS operation system dumped internally the EEPROM, it concluded correct checksum so did not load the default EEPROM inside the RAM.Maybe one last question about the firmware management of these TDSxxx-C scope which you described yesterday. Suppose indeed for some reason the EEPROM content is full of zeroes. It happens unfortunately that tektronix did not check that case in their SW design so this ends up with a valid CRC check when the software reads the EEPROM. I guess in that situation the TDS operating system will never attempt to use the EEPROM default values found in the firmware because it concluded good checksum... same old issue as you did find with your first java-checksum application where now you have reinforced the test by excluding all zeroes. However what happens then with calibration constant loaded to all zeroes, the scope thinks everything is OK with calibration constants and so except they are all zeros ?Furthermore as mentioned before, my intent is to later attempt finding the proper connector, cable and driver driver to actually check via terminal console on my Macintosh the RS232 Console port information via the J40 processor board interface.Amicalement, Albert

author: flyte
author_rank: Regular Contributor
timestamp: January 27, 2020, 05:08:30 pm
content: Quote from: Tantratron on January 27, 2020, 03:19:38 pmBut software reading leads to a dead end for your bad board, you get either defaults or zeroes, so you'll have to get that soldering iron out. If you do care about the constants as you mention it, that would be your only option at this point.Quote from: Tantratron on January 27, 2020, 03:19:38 pmI've now checked your originally posted EEPROM-TDS540C.zip as well and the two dumps areverydifferent. It's the same structure, sure, but it's like 75% difference just byte-wise. The 2G dump seems normal, the 1G has the exact same values as the firmware defaults and it is the byproduct of the way the GPIB tool reads (i.e. initialized shadow space rather than a fresh hardware access).Quote from: Tantratron on January 27, 2020, 03:19:38 pmNo that's not the case. It was just a somewhat unfortunate side effect of my checksum tool. The real firmware will verify the checksum as valid but it will also notice due to other parameters the store doesn't contain any values at the indices of interest. So loading all zeroes will get you a CPU FAIL ExtCal. However, whether or not it will proceed with a default value initialization or just leaves the zeroes it read in RAM at certain points in time, depending on when your GPIB read exactly intervenes as this is a concurrent VxWorks task if I'm not mistaken, I'm not sure. It should, in case they've done the job right.Alright, good luck with the soldering iron, I hope you do discover some values in there instead of the bunch of zeroes you're faced with for now!

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 27, 2020, 06:43:41 pm
content: Quote from: flyte on January 27, 2020, 05:08:30 pmOk I've taken the time to inspect both PCB faces of the Bad Acq-Board in the EEPROM zoning in order to be able probing later in the week the key signals (SDA, SCL, GND and +5V). After this I did re-install the bad Acq-board inside the bad TDS-1G then performed some Floppy-dump and GPIB-dump. It seems not possible to probe the WRITE-Enable trace from the PCB-top once re-installed.See attached a ZIP containing 4 folders, each folder corresponds a scenario with Floppy and GPIB dumps. What is now SUPER wierd, wether installing good Acq-board or bad Acq-board in the failed TDS540C-1G will always return full of ZEROS if dumping via GPIB. Few days ago this was not the case as you saw on my previous ZIP even though their content clearly showed problem. Are we OK that the GPIB only dumps the RAM content which is supposed to be a copy of the EEPROM if checksum correct or copy of the EEPROM default stored in the Firmware ?Do make a note that unless i'm wrong, wether the EEPROM is still OK or not, wether we dump by Floppy... the dumps will always have to transit through the ADG308 in charge of the I2C management (bottleneck bus situation). My point is that maybe the EEPROM is corrupted and now full of zeros, the Floppy dump returns sometimes all ZEROS, other times all FIVES... however I'm afraid the Acq-Board has multiple issues (maybe ADG308) because it does not make any sense to have correct Floppy dump EEPROM file of good Acq-board when installed inside bad TDS-1G but wrong GPIB dump full of ZEROS (here the Acq-board is the good one)...please folderTDS1G-Good-AcqBoardin the attached ZIP file. Lastly as a reminder, when installing good Acq-board into the failed TDS-1G then the scope passes all self-tests where I did push the exercice to run complete SPC which was fine !

author: flyte
author_rank: Regular Contributor
timestamp: January 27, 2020, 08:43:24 pm
content: @TantratronDon't get me wrong, but you each time you try all sorts of swaps and readouts, you are simply increasing the likelihood of ruining your calibration constants EEPROMs. Why that is? Because you still have no EEPROM backup at this point and you are probably dealing with a hardware failure.So it could happen - it just could at a certain moment - your persistence in innocent software reading attempts is sending some wrong messages over the I2C bus due to hardware defects, inadvertently issuing write or erase commands, for example. It's like the first rule of computer forensics: don't touch it, leave the data state intact.Yes, the I2C traffic always transits through the ASIC, it can't go elsewhere, can it?But the dumps as such, no. If you read via the GPIB tool, as mentioned several times, you are actually reading from RAM and you can hope (or not) the firmware properly initialized that section with the data from the EEPROM. That likely didn't happen or failed on some occasions, as it did put defaults in there. It's very unlikely these defaults actually come from the EEPROM by accident. In case you read with the floppy script, it's a direct hardware call to the ASIC/I2C.You say some observations don't make sense. They do, always. Unless it's yet another theory on particle physics or the origins of the universe.It's just we/you can't see the whole picture of the edge cases the firmware is operating in and what it is doing in that exact case.Your acquisition board may certainly have multiple issues. You could fix all of those, in theory at least. The only thing which you can't fix easily, is getting those cal constants back. Hence you should concentrate your efforts at getting those out of the EEPROMs asap safely. In my humble opinion, which seems shared by other members, this is only possible by removing them and reading them externally, if it's not too late already.Btw, did you check silly things like the pullup or pulldown resistors on the SDA/SCL bus? Or signal levels? That would be one of my first suspects and a very easy thing to check.EDIT: just checked your uploaded files. You get 0x0000 and 0x5555 as data result from the floppy dumper. 0x5555 is 0101010101... in binary. This smells like an I2C level or clock feedback problem. I would bet on a bad pullup resistor and a floating bus data line, because if the EEPROMs were bad, it's a bit less likely they're bad two at once. Of course, one could be bad and pull down the bus. I don't even care what the GPIB tool did, it does not matter.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 28, 2020, 06:57:23 pm
content: Quote from: flyte on January 27, 2020, 08:43:24 pmI see your point but I come from digital signal processing industry as well as radio electronics. My feeling was these TDS are really more digital or software oriented where roughly the only analog part is the acquisition board. So far I was using legacy tektronix 2400 serie so I'm on my learning curve with TDSxxx. However my assumption (maybe I'm wrong) was that if reading whatever memory then there should not be writing access. Usually when I repair stuff in the industry (avionics, radio...), the cannibalization technique is safe or I'd say is the quickest. You replace one suspect sub-system by a working system to isolate which one is faulty. This logic works very well when there is one failure but if multiple failures, there are dependencies hence one can get lost. In fact that is what happened to me with this scope even though I'm very happy because learning lot on this TDS xxx family which I feel investing more to use them, keep them.What you describe is kind of catastrophic scenario where any test would destroy the machine. Maybe you're right here but usually any good electronic equipment with good software has built-in protection like fail-safe or detect then stop to avoid a runway destructive effect.As for the EEPROM topic, honestly in this forum and the tek forum only one member @charlyd reported the same type of error log so this EEPROM topic is very seldom. This is why I felt not enough evidence to conclude it was my EEPROM then went on the route to swap and dump from different views. In fact I've learned thanks to you in this thread that getCalData is copy of RAM of either good EEPROM if checksum is OK or copy of default EEPROM stored in Firmware. If I'd have known this before, for sure I'd not have lost my time going along with many swaps, dumpings and false interpretation.What is certain, I did the test herehttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2860746/#msg2860746. The failed TDS-1G once installed a good Acq-Board-2G works fine but what I've discovered later, there seems to be a GPIB issue or something else. The TDS-1G processor-board might be the problem because it does not make any sense with good Acq-Board to GPBIB-getCalData only ZEROS from the RAM copy since the EEPROM. In that test, the Acq board is good, the EEPROM are good so I only kept the 1G-Processor board which pass self-test but does NOT match the BIN files of EEPROM. Your Floppy-script provides the good EEPROM content but the GPIB-dump shows zero. Once I re-install the good Acq-board into the good TDS then every works: your floppy-dump gives exactly the same content of the EEPROM than the GPIB-dump.So I suspect even though maybe I'm wrong, the failed scope has another partial failure on its Processor-board.Quote from: flyte on January 27, 2020, 08:43:24 pmBefore embarking into de-solder the EEPROM, today I took some of time to try reverse engineer and look patiently of the PCB traces near the EEPROM but also the NVWR protect parts. I did check the electrical continuities of that circuit, so far I did not see any issue then I connected my good old tektronix 2465 with a P6136 probe to check the values of different test signals related to U1052 and U1055 chips (+5V, GND, toggling effect of protection write switch)...The WC (Write Enable) is always HIGH (5V) whereas NVWR_EN stays LOW so there will be never write access to both EEPROM. Once scope started after a while, I toggle the protect switch, the WC became LOW (0V) while the NVWR_EN becomes HIGH (+5V) so this validates the U1061 chip translation of the NVWR_EN signal to be correct.The Vss and Vdd of the chips are OK on different parts of the PCB as far as I can tell.However the SDA (DATA) seems always HIGH and the SCL (Clock) always LOW.Since I've never probed the SDA and SCL of this TDSxxx serie C, I've no idea what time div frequency scale neither when to look for the CLK or DATA modulation after booting the scope. Maybe you could advise on what best testing strategy to check the data line and clock line once I start the TDS540C... at what moment the ADG308 will engage in the I2C protocol to read the EEPROM, how can I capture the modulation...Thank you, Albert

author: shakalnokturn
author_rank: Super Contributor
timestamp: January 28, 2020, 07:32:51 pm
content: I'd set acquisition for single and trigger for more than one state change, see if that gets you anything on a power-up.

author: flyte
author_rank: Regular Contributor
timestamp: January 28, 2020, 11:22:52 pm
content: Quote from: Tantratron on January 28, 2020, 06:57:23 pmThe scope will read the I2C at startup and also, obviously, when you run the EEPROM floppy dump script. Set your trigger (I mean, on the equipment you're using to diagnose) to single shot mode on the SCL line, put SDA on the other scope channel, and with the first clock transition you should see whether anything happens on that bus or not. I2C is usually in the 100KHz range, it's slow.In case you want to know whether your CPU board is good or not, I'm repeating myself here, swap it with the CPU board in the fully working unit. But just the CPU board, as the fault could also be located in the cables, the connectors, some power supply line, whatever, you just don't know. I'm not sure I understand why you keep on insisting to find an explanation for the wrong GetCalData GPIB read, it's irrelevant at this point. It could be a side effect of something you're overlooking at this point. If the CPU board fully works inside the other good unit, then it's good. If not, then it's bad. Pretty straightforward. When testing this, don't forget to load the NVRAM of the "good" unit into the CPU board you're testing/suspecting. Both boards should have the same firmware, same dip switch settings, same NVRAM content ... i.e. they should be identical as possible. Only then you can draw conclusions and isolate the fault.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 29, 2020, 09:18:16 am
content: Quote from: flyte on January 28, 2020, 11:22:52 pmThis morning I woke up much early to do some comparative test on SCL and SDA single-probed then displayed with my tek 2465 scope before doing my daily job. The 2465 time division set to 100 ms enough to see drastically different behaviors after starting, re-starting multiple times each Acq-Boards ASIC-EEPROM communication.Attached two new updates pictures showing both faces of the Acq-PCB zoning being focussing on the ADG308 Asic, the X24C02 eeproms, the unique Pull-up resistor (R1065 for SDA) and unique Pull-down resistor (R1060 for NVWR_EN) related to the U1721 chip.I've re-checked again many times for any PCB trace discontinuity or local bad soldering, it is seems OK.Make a first note both WR pin (X24C0-7) always show HIGH (+5V) when probed plus the only pull-down resistor is related to that sub-topic via the U1721 XOR chip translating the Protect switch order (there is no way the EEPROM can be written).The only PULL-up resistor is the R1065 which works perfectly wether DMM check then later probing SDA (Data).This implies on a side note that the SCL (Clock) from the ASIC does not have any pull-up or pull-down resistor in the TDS540C design.I did not have time to record, trig the SDA and SCL because I consider the following visual tests with my P6136 and my tek 2465 to be enough proving there is either (1) an ASIC problem (internal or external control from the 68040 or who ever communicates with ADG308 to dump the EEPROM content) or (2) an EEPROM problem.Tests on good TDS540C:At start the SCL is HIGH (+5V) then after a while there is clearly a clock modulation (between 0v and 5V) then stays LOW (0V) for few seconds. After a while again clock modulation and finally always stays LOW.At start the SDA is HIGH then after a while data modulation (much lower freq than SCL clock modulation) then stays HIGH for few seconds. After a while again clock modulation and finally stays HIGH.It seems like the OS of the TDS will attempt to read again the EEPROM but I could be wrong in this conclusion.Tests on bad TDS540C:At start the SCL is HIGH then always stays LOW.At start the SDA is HIGH then after a while short glitches between 0V and 5V then always stays HIGH.There is no 2nd attempt to read the EEPROM like in the heathy TDS above test.Question 1:Does anyone know if both EEPROM are removed then does the IDG308 would still generate the SCL (Clock) and SDA content attempting to readQuestion 2:What electrical test could be done on the EEPROM still soldered in my Acq-board which could indicate some internal short-circuit or something else implying the SCL output from ASIC to be voided or neutralized or inoperativeQuestion 3:What is the role of ADG308-108 pin input which is referred as IC2_DIAG and connected to the output of the U1721 who seems to keep track of Protect switch S1002 status (write protect disable or enable)Quote from: flyte on January 28, 2020, 11:22:52 pmI do not wish to debate on what you have been suggesting here and before because what you describe could create more problems in my opinion. Please do not be offended, I'm not saying you right or wrong but I've repaired much more complex electronic and digital system like Airbus avionics. The method of troubleshooting I prefer to follow: modular test engineering versus component test engineering. The TDS scope can be seen simply as few different main sub-systems, of course inter-connected by busses, cables which dialog via different chips, uC, ASIC... technically speaking, the processor-board of the bad TDS is partially working which is why once connected with health Acq-board then the Scope self-test OK. The only strange thing which i've already mentioned, for some reason the GPIB-GetCalData dumps ALL zeros so maybe the GPIB is partially failed whereas your community-contribution (Floppy-dump and Floppy-Write) set provides the good content of the EEPROM.Some of the test house companies I know in France when they have a failure and send to repair to tektronix or their OEM repair center, tektronix company changes the boards and not spend to much time as we're all doing here. Plus they charge huge money so their customers would prefer buy new scope to feed electronic obsolescence business model but that is another philosophical topicAnyway I prefer to go step by step, after all I'm on my learning curve with this TDSxxx serie C totally new for myself. My today earlier test clearly show there is an issue between ADG308 and the EEPROMs but not necessarily EEPROM itself. Wether the processor boards are good or bad does not change anything, when I did install the bad Acq-board into good TDS o rinto the bad TDS, the self-test Fail ++Processor.I really want to thank you again to have developed the Floppy-dump and Floppy-write along with your fundamental explanation of checksum failure EEPROM read implies a local RAM copy of CalData from the Firmware. From these different Floppy-dump and GPIB-GetCalData test done on both swap, I did converge to learn then now focus on the EEPROM and ADG308 topic which is clearly failure number one in this oscilloscope.Later i'll see how to use the possibility to RS232 Console Port the J40 connector which might provide much more refined error log than the synthetic error log provided as standard.Warm regards, Albert

author: flyte
author_rank: Regular Contributor
timestamp: January 29, 2020, 02:15:30 pm
content: Quote from: Tantratron on January 29, 2020, 09:18:16 amSure, why not, as long as the pullup on SDA is there and as you said yourself the SCL must be driven with levels straight from the ASIC. Good to see you're closing in on the idea of EEPROM removal, eventually!Quote from: Tantratron on January 29, 2020, 09:18:16 amA conductivity test using a multimeter. But that's only gonna show a really bad short circuit, not some unexpected pull down in the circuit. And you still won't know whether look left or right, i.e. ASIC or EEPROM, unless you remove one of them. Odd we're always coming back to that removal suggestion.Quote from: Tantratron on January 29, 2020, 09:18:16 amNo idea, I didn't design it. Perhaps to detect whether you flipped the switch or not, or some additional write safety mechanism fed into the ASIC.Quote from: Tantratron on January 29, 2020, 09:18:16 amYou questioned that CPU board in the first place. So I offered you a very modular testing solution to it: swap it with the CPU in the good unit. Now if that CPU board is suddenly no longer important to check or would create more problems, so be it. If you've repaired more complex systems than this, then you should know how to proceed and I'd assume, given the references you've just made, you know how to remove those EEPROMs in perfect shape. Not to speak personal here let alone how many academic degrees we all have, but bear in mind many people on this board are actually software and/or hardware design engineers. So most of us do know a couple of things about complex matters and systems as such.Quote from: Tantratron on January 29, 2020, 09:18:16 amIt does point into that direction and it's very likely indeed, as nearly everyone on this thread has suggested. But clearly show it? Nope. It may very well be there is some communication (bus, cable, whichever other component sits in between or controls it) issue happening before the ASIC which manifests itself in bad or unexpected signalling at the I2C bus.And, practically speaking, how would you then plan fixing that, other than by removal of the cheapest and easiest component? I'd pick the 50 cent EEPROM to start the removal with and put my suspicion on, not that 200-pin ASIC. But hey, the choice is yours!If for example that scope is still able to trigger with that bad board, than chances the problem is with the ASIC or before it lower drastically. But I'm not sure it actually can with the bad cal values of course.Besides, in case you remove the EEPROM and it would indeed be dead, then you had no choice but to replace it. In case it's still working, you should hurry up and get the calibration data out asap. I'm missing any drawbacks there.Quote from: Tantratron on January 29, 2020, 09:18:16 amYou're very welcome and I'm happy it's useful to you, but in the first place I released the write tool hoping it may serve the community.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 30, 2020, 07:02:26 pm
content: Quote from: flyte on January 29, 2020, 02:15:30 pmTonight I've powered the scope, then after some 30 min warm up time I did run the SPC even though it has the Fail ++Processor. The SPC passes except as reported few weeks ago, the Voltage reference, frequency response and Pulse Trigger stay initialized.Then I've connected on each channel one P6139A probe which senses the Probe calibrator 1KHz signal output.: each channel will properly trigger.

author: Tantratron
author_rank: Frequent Contributor
timestamp: February 01, 2020, 11:05:50 am
content: This morning decided to solder some wires into the SDC (CLK green wire) and SDA (DATA red wire) between ADG308 asic and both EEPROMs of the failed Acq-board then partially re-installed the all unit (the black wire is GND)Attached some pictures of triggered results using the healthy TDS540C with two P6139A probes, please see time stamping where Ch1 (top view) is the CLK whereas Ch2 is the DATA. I did trigger basic but that might not be the best choice or combination.However we see at time 11:30:45 this is first recorded event after boot (the clock rings a few cycles and I guess some data is sent to request reading). MUCH later at time 11:31:52 there is only one CLK pulse coming after DATA huge pulse...

author: SaabFAN
author_rank: Frequent Contributor
timestamp: February 01, 2020, 02:34:12 pm
content: You might have an issue with probing the i2c-Bus, which gives you false readings: You're measuring a databus that runs at a minimum of 100kHz with a sample-rate of 100kS/s.Try to use at least 1 Megasample/second. Especially since there's a possibility that the i2c-bus can switch to Fast Mode, which would mean 400kHz Clock-Frequency.

author: Tantratron
author_rank: Frequent Contributor
timestamp: February 01, 2020, 03:17:12 pm
content: Quote from: SaabFAN on February 01, 2020, 02:34:12 pmThank you @ SaabFAN for the suggestion were in fact both TDS540C do have 1M options so I've lot of margin to trigger, store then zoom. Attached a new updates of the I2C probing sampled at 2.5 MS/s where as a reminder there are two moments or type of events once the scope is booted.

author: SaabFAN
author_rank: Frequent Contributor
timestamp: February 01, 2020, 04:07:05 pm
content: Without reading all the previous posts, I'd hazard a guess and say that there's a chip that does "clock stretching" (a technique by i2c-Slaves to slow down the master in case they are still busy working on the previously received data).But in this case the clock-stretching goes on forever until the chip times out.I2C-Busses should always float high when there is no activity.Since those chips are SMD-Components (I read you were reluctant to desolder them), I'd say there's only a small risk of damaging them or the board with hot air and then testing them with an Arduino. If you're worried about accidentally erasing them, just tie the Write Protect-Pin to the correct level to prevent any write operation.With the chips desoldered you can also see if there's another chip pulling down the bus. And you can make a dump of the data. If the EEPROMs are damaged and not working correctly, you might be able to read them by increasing the voltage a bit until you finally get the data. That method worked for me with an older parallel EPROM that had started to exhibit bit-errors. With the voltage cranked up to 6,5V I was able to reliably read the chip and re-writing it. After that the device with that chip in it didn't crash any more.I still replaced the chip though. Just to be sure.Just make sure you remember which chip goes whereEdit: Just had a more closer look at the pictures and I noticed something.The Clock-Signal has varying periods. Either a chip is doing clock-stretching on a period-by-period basis OR you have a bad main oscillator / PLL somewhere.Have you checked other clock-signals for similar behaviour?

author: ragge
author_rank: Regular Contributor
timestamp: February 01, 2020, 04:57:29 pm
content: It is hard to say since the timing of the individual edges are important, but I think I can read this:This looks good and bad.It seems there is an initial transition on CLK that has nothing to do with it; themA start condition, the address + READ (1 0 1 0 0 0 0 1(R)), then it does one clock cycle to let the EEPROM acknowledge but it doesn't, then a stop condition.Then five more retries of: start condition, addressing, no ack, stop condition.So it seems like the ASIC and the I2C bus are OK, but the first EEPROM does not respond.Maybe the second one still contains good data, and maybe that can be reused with the right knowledge of things.This would mean that all the expensive parts are good, but the calibration data may be lost.I would remove the EEPROMs and try to read them with something else, then install new EEPROMs.Since others have managed to calibrate the scope without the calibration data from the EEPROMs, there is hope.And thanks to Flyte, you can now program the new EEPROMs when in the scope, and even experiment with different calibration sets.By the way - you can read about how the protocol works in e.g. almost any 24C02 data sheet, or most other I2C device data sheets, or from some general I2C documentation.Ragnar

author: ragge
author_rank: Regular Contributor
timestamp: February 01, 2020, 05:25:59 pm
content: Quote from: SaabFAN on February 01, 2020, 04:07:05 pm(FYI: This is not really a normal I2C bus - there is no pullup on SCL, so it must be actively driven both up and down by the ASIC.)I think the host just gives up and forgets to reset the SCL.Quote from: SaabFAN on February 01, 2020, 04:07:05 pmActually it is quite tight except for the start condition, stop condition and the ack cycle, I think it looks entirely normal.But it is quite common for software driven I2C buses to have varying clock cycle lengths, and it should work anyway.

author: Tantratron
author_rank: Frequent Contributor
timestamp: February 01, 2020, 06:53:00 pm
content: Quote from: SaabFAN on February 01, 2020, 04:07:05 pmThanks a lot for teaching this tip of slight over-voltage to re-read the content of EEPROM.I plan as next stage to desolder both EEPROM's then read them arduino style but first I want to make sure the ADG308 asic in charge of the I2C is not at fault since I have another strange effect with this oscilloscope.When I did test the good TDS540C, there were clearly two attempts to read the EEPROMs as i've reported in this previous posthttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2892782/#msg2892782These two attempts are spaced at least 10-20s each during the boot, no idea if it is a double read check. However I wonder what could be the explanation in the failed TDS540C, see attached again both scopeshots corresponding to the 2nd major event between the ASIC and the EEPROMs. The bottom trace (Ch 2) is SDA, the top trace (Ch 1) the SCL so why it suddenly DATA decides to go LOW and the unique SCL pulse happens much after... wierdIf I had more time and not worried to make a false move, I'd deconstruct the good TDS540C then solder the I2C wires to see exactly what is the complete protocol when everything works OK.Thank you, Albert

author: shakalnokturn
author_rank: Super Contributor
timestamp: February 02, 2020, 12:52:14 am
content: FWIW, I don't have that much experience with I²C other than checking logic levels, reading and sometimes rewriting/blanking corrupt EEPROM's out of the host system.To backup SaabFAN:Your waveform captures reminded me of one of my first experiences, (some 25 years ago) with I²C that must have been on a Philips TVC15 with AST (for those who remember...).Probing with the CRO showed some startup activity, then the typical regular pulses you're seeing.I remember it was repaired by replacing a 93C46 or 93C56... That taught me one of the basic checks I still use regularly when troubleshooting, in this order when applicable:PowerOscillatorsResetSerial busParallel buses

author: Tantratron
author_rank: Frequent Contributor
timestamp: February 02, 2020, 11:22:29 am
content: Quote from: SaabFAN on February 01, 2020, 04:07:05 pmI've read bit this morning the I2C norm fromhttps://i2c.info/i2c-bus-specificationandhttp://www.i2c-bus.org/fileadmin/ftp/i2c_bus_specification_1995.pdfwhere unless i'm wrong, the SDA should always go LOW before the SCL in order to launch a START condition.Attached new screenshot taken this morning from the failed TDS540C where I've now permuted the signals so upper channel is SDA and lower SCL to be similar to most figures found in the datasheets, documents on I2C.Unless I'm wrong, the very first activity of the ASIC to communicate with EEPROM seems SCL while the SDA keeps HIGH which cannot validate a START condition. How does the EEPROM will sync or understand the first command from ASIC attempting to read it ?As for your questionHave you checked other clock-signals for similar behaviour, which ADG308-pin would check (see attached page 269 showing the complete circuit around this ASIC and the EEPROM) ?On a side note, does anyone knows why tektronix decided to not have a pull-up resistor on the SCL line since most literature recommends two pull-ups, namely pull-up on SCL and pull-up on SDA ?

author: madao
author_rank: Frequent Contributor
timestamp: February 02, 2020, 12:34:02 pm
content: Here a pictures with notice of start state. I2C device is waked, if start state come. No start state = All I²c devices stay inactive.It choose U1052 EEPROM with write commando (it means not EEPROM write !)

author: madao
author_rank: Frequent Contributor
timestamp: February 02, 2020, 01:18:39 pm
content: EEPROM IS DEAD. It doesn't make a ACK !

author: ragge
author_rank: Regular Contributor
timestamp: February 02, 2020, 07:37:21 pm
content: Quote from: madao on February 02, 2020, 01:18:39 pmYou could see that (but not as well) on the earlier pictures, and I said so a few comments up.Are my comments not visible?

author: madao
author_rank: Frequent Contributor
timestamp: February 03, 2020, 05:25:44 am
content: Honestly, i haven't read all, because: I haven't desire to read this theard, which we know since long time ago: EEPROM is problem and it isn't replaced. Many talk , less action.Albert wrote me a mail (Quesition about I²C start state) and i answer it based their mail . What i see : no ACK from EEPROM.Albert has now two same clear answer (from you and me) Now, he must replace EEPROM.Everthing else measure and action without replacing of EEPROM is waste of time. Only one solution: replace EEPROM.greetingsmatt

author: ragge
author_rank: Regular Contributor
timestamp: February 03, 2020, 12:14:31 pm
content: Quote from: madao on February 03, 2020, 05:25:44 amOk, good!

author: shakalnokturn
author_rank: Super Contributor
timestamp: February 03, 2020, 12:53:25 pm
content: This is going to turn out as the longest wound 24C02 replacement on the forum

author: flyte
author_rank: Regular Contributor
timestamp: February 03, 2020, 07:13:58 pm
content: Quote from: madao on February 03, 2020, 05:25:44 amThat would be a premature conclusion. There's a ton of options left for this already record-breaking thread:- decap the EEPROM chip and determine which bond wire broke- examine it under an electron microscope- perform a die microprobing attack in order to read it- get the semicon manufacturer involved and assess the situation- ...

author: Tantratron
author_rank: Frequent Contributor
timestamp: February 04, 2020, 02:03:32 pm
content: Quote from: shakalnokturn on February 03, 2020, 12:53:25 pmQuote from: flyte on February 03, 2020, 07:13:58 pm@shakalnokturn @flyteThe thread is quite long because it covers different topics plus there has been different hypothesis by different members.On page 1 there was @madao saying the problem was due to NVRAM DS1486 and suggested that I upgrade from 1G to 2G the acquisition board. As I did not have for the moment memory programmer plus I only use Macintosh, it took a while to get the GPIB work and thank to the collecting work of @ragge, I was finally able to upgrade the firmware, to dump and write new NVRAM. Some other members said it was the log file going overflow... many theories where it turned out the problem was not the NVRAM.I made some mistake understanding the instructions to upgrade to 2G but finally worked per the instructions of @madao plus I was securing the use of my USB-GPIB from my MacBook Air to non-invasive read-write the NVRAM, the flashfile which brings us to the core topic on page 3.At that moment I decided to install the good Acq-board into the fail TDS540C, it worked so for sure the problem was not a Fail ++Processor as claimed by tektronix but a Fail ++Acquisitionhttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2860746/#msg2860746My feeling since the topic was new for me plus it was the 1st time I discover these TDS then I'd prefer to look on internet (EEVBlog, tekforum) for similar reported failure then I've found the threads of @charlydhttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2868584/#msg2868584https://forum.tek.com/viewtopic.php?t=138489For the first time, there was a real repair describing the root cause from @charlyd, namely the EEPROM chip but I was not sure to fully understand the explanation, in fact @ragge was the samehttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2877512/#msg2877512It is quite ironic later on page 4 that @shakalnokturn suggest that I swap the other boards which I hesitated during few dayshttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2880974/#msg2880974Finally on page 4 there was the only serious and sound engineer explanation by @flyte on what was happening, the root cause so I took time to verify, understandhttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2886008/#msg2886008However I got again confused because for some reason the local RAM copy of the default Cal were all zeros so I started to suspect another failure in the processor boardhttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2889560/#msg2889560Later on page 5 there has been some philosophy disagreement between software testing and hardware BUT the key point you need to realize, there was no rush, there is no rush. I have a working TDS540C to use for my little consulting company, I do not have too much spare time due to work and family duties (wife, two children).Furthermore I made clear many times to only use Macintosh, to not have the FAS adequate equipment for that scope, no programming tool for the moment and I wanted to interface my Mac via RS323-USB interface to the J40 debug consol port as a next stage.I decided to probe finally the I2C bus lines and learning the low level coding of I2C bus which was new to me, finally it was clearly established the EEPROM to not send any data to the ASIC, see page 5https://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2892782/#msg2892782As a reminder, this TDS540C which was imported from a USA lab to a french lab had a long story of failure (check attached the log file from 2003) where now I suspect the ERROR:250mass storage error with READ fail was probably the EEPROM (NV250) hence my reticence plus its front panel is partially brokenhttps://www.eevblog.com/forum/repair/tektronix-tds540c-cursor-partial-failure/msg2809344/#msg2809344Anyway the point, if this thread is too lengthy or not interesting, just don't read it and click UNOTIFY. If you do want to help, just accept that I'm not the employee of anybody, my time is constrained with other activities, I'm not in rush to repair this TDS but rather invest my time to learn this TDS serie totally new for me to decide if I'll keep for my consulting companyhttps://www.eevblog.com/forum/repair/tds-500-and-tds700-series-a-b-c-or-d-what-subsystem-are-common/msg2831168/#msg2831168One thing which worries me by the way is the lack of solution about the NVRAM battery failure... What is now certain, we have two similar failures log message from @charlyd and @tantratron which will save time in the future for others even though it seems this EEPROM failure is not very common.From my point view, this thread and these others had helped me lot learn from scratch the basic of TDS plus keep my MacBook Air to use the GPIB to do many things like dump, write, setting options (FFT)https://www.eevblog.com/forum/repair/gpib-usb-control-between-macbook-air-(macintosh)-and-tds540c/msg2835780/#msg2835780https://www.eevblog.com/forum/repair/tekfwtool-for-tds540c-firmware-upgrade/msg2845956/#msg2845956https://github.com/ragges/tektools...Special thanks for @charlyd (first to have repaired this fault) @madao (many tricks and patience) @ragge (GPIB-USB repository valid for Mac) @flyte (floppy stuff and clear explanation).In the meantime, I'll try as a project to find a method to Macintosh TERMINAL read what the J40 detailed debug says in general with the EEPROM still soldered. After i'll de-solder both X24C02, will build a quick&dirty arduino style programmer (read, write), will replace the EEPROM and will find someone with required tools (PC, DOS, high frequency generator) to do the calibration(the FAS does not run on Linux neither MacOS).Patience is a virtue...Thank you and peace, Albert

author: charlyd
author_rank: Frequent Contributor
timestamp: February 05, 2020, 11:23:09 pm
content: feeks like were are back at post #72 …..

author: madao
author_rank: Frequent Contributor
timestamp: February 20, 2020, 02:05:02 pm
content: I had a lots of thoughts and times about what to write in this topics.Sorry, albert. I have written, that every action without replacing of EEPROM is a waste of time.People of eevblog wait on the result after two very clear answers (EEPROM is dead) and some users have experience with dead EEPROM.What did you do? You wrote a topic with other question (not important for fixing) and didn’t show a result about the EEPROM. Of course, most people - including me - are annoyed with this „result“. It is similar to repairing a car: people tell you the wheel bearing makes strange noises and you ignore this noise up to the point, when the wheel rolls away and the bearing is broken. Of course , people don’t tell you after a few times about this noise and they think: not my problem, if he doesnt take this notice about the bad bearing seriously. It is really not funny for many people, we want help and share experience and are disappointed with this result.You have gotten my offer of fixing this fail, but i wait and wait and wait….. (I know: you wait on an answer from university.)Indeed, i must cancel my offer to save my time. I have told you, I have much less time since spring (other hobby, car, nissan R34)GreetingMatt

author: Tantratron
author_rank: Frequent Contributor
timestamp: February 21, 2020, 10:21:30 am
content: Quote from: madao on February 20, 2020, 02:05:02 pmI'm sorry Matt but what you said is wrong...As i've already mentioned, you did first write the problem was NVRAM on processor board (CPU board), you did ask I upload NVRAM's... I had to wait to get my MacBook Air to run with GPIB-USB and tekfwtool but NVRAM upload never solved the problem (check page 1 to page 2). Of course I thank you because you did provide very good help to upgrade from 1G to 2G the acquisition boardhttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2856924/#msg2856924Later on page 3, I've solved the problem from a system level by proving it was Acquisition board to be the problemhttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2860746/#msg2860746At this moment we All discover that tektronix troubleshooting display is wrong, namely it says FAIL ++Processor whereas it should state FAIL ++Acquisition. In fact @shakalnokturn wrote about this paradigm or strange situationhttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2860990/#msg2860990After all we're not shaman to discover hidden information so it would have been better for tektronix firmware to correctly troubleshoot by saying Fail ++EEPROM on Acquisition board...Different members including yourself from this moment suggested it was the EEPROM to be damaged but I hesitated to repair the Acquisition board (replace the EEPROM) because I had another strange failure or effect from the Processor board... seeRED sentencein this posthttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2889560/#msg2889560Furthermore I did not have a programmer neither a spare 24C02 chipset and most important, neither had all equipment to perform a full calibration so why spend time to desolder. As a reminder I have another TDS540C which runs very good and I'm using for my daily activities for my company.What is certain, the only member who did solve the same problem was @charlyd on this posthttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2868584/#msg2868584Quote from: charlyd on February 05, 2020, 11:23:09 pmYeap plus later I finally probed (after many posts) the I2C signals of both EEPROMs to confirm they did not respond to the ASIC read attempthttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2899120/#msg2899120thenhttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2899212/#msg2899212Anyway here is a status of my repair as of february 5th... on january 8th before going through many swapping, uploading and I did DUMP (save) both TDS540C firmware's and NVRAM's as a safety procedure. So on february 5th I dediced to upload the january 8th version of NVRAM's in the failed TDS540C and guess what, now the getcaldata reads the correct default EEPROM values from the firmware. This means that @flyte was right of risk to brick the scope by all these swapping, readings, writingshttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2890442/#msg2890442So I was lucky to have saved NVRAMs early january and now the acquisition board works fine again, namely it sees the EEPROM is wrong using getCalData via GPIB-USB so it stores default calibration values from the firmware as explained by @flyte herehttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2886008/#msg2886008My intent is soon to de-solder both EEPROM, build an arduino style programmer to see if one can be read. Of course I'll buy two EEPROM and solder them back BUT my real problem is no tools in my company for the moment to properly run the FAS.Best regards, Albert

author: charlyd
author_rank: Frequent Contributor
timestamp: February 22, 2020, 09:41:55 am
content: Hi Albert, as i mentioned before change both EEproms with new EMPTY onces and start to calibrate…clear the error log, after soldering and putting things back together. A friend of mine has his own website with some nice TDS tools, here is one you could use.http://www.hakanh.com/dl/TDSErrLog.htmand see what comes back your "FATAL: 250 NVstorage too small more bytes requested then available" should be gone.only a message:"nvlibrarianDiags, libs with crcc failures: , ExtConst" or so will be still visible in the log, which points to the calibration with the FAS.what and how to do. read back if some of my forst posts.Did you ever fix the console port adapter which is connected on the cpu board through the RS232 hole. ??but ok, remember your error log is your reference for having placed working chips@Ragge, yes the FAS writes the Eeproms.But what could be the real reason that these EEProms start failing over time, in a particular range of models?

author: shakalnokturn
author_rank: Super Contributor
timestamp: February 22, 2020, 11:37:08 am
content: Quote from: charlyd on February 22, 2020, 09:41:55 amSomething to do with them not using the usual pull-up scheme on the I²C bus?

author: Tantratron
author_rank: Frequent Contributor
timestamp: April 03, 2020, 09:37:23 am
content: Quote from: Tantratron on February 21, 2020, 10:21:30 amFirst I hope most of you are OK with the Covid19 issue wether on health and economical.On my side with my small consulting and testing company, it is a mess like most companies in France or everywhere worldwide whatever the industry with impossibility to do any business development, do or win new contracts... so I have lot of time due to confinement during april.Attached some pictures where I've finally un-soldered both X24C02 (Xicor) then re-soldered two new 24C02H (On Semi). I was able via eBay to purchase 20 of them for 10€ last week and they got delivered earlier this week.It seems this time much less error log messages where as predicted by some of you, the U1052 fail to be read from the ASIC was creating the NV or not enough memory. However there is still the Partial Fail ++Processor and diagnostic error including the wrong CRC.Maybe this is due to the fact I've not calibrated the scope (no tools for this as of today) neither programmed the 24C02H prior soldering where these are brand new. Even if I had a programmer, I do not have access to the proper content of the EEPROM so I just soldered them to see the result. So I'll try later make an arduino EEPROM reader to see if one of the X24C02 has the philosopher stone data of that specific acquisition board.I'm fully aware of the option to use @flyte floppy driver method to re-program the EEPROMhttps://www.eevblog.com/forum/testgear/tektronix-tds500600700-nvram-floppy-dump-tool/Best wished during this very hard times with the coronavirus pandemic affecting all countries.Albert

author: Tantratron
author_rank: Frequent Contributor
timestamp: April 03, 2020, 02:31:50 pm
content: P.S. Here is a final update where the TDS540C now pass the self-test as well as the SPC even though no calibration.I've used the tool set of @flytehttps://www.eevblog.com/forum/testgear/tektronix-tds500600700-nvram-floppy-dump-tool/msg2887352/#msg2887352to read the EEPROM then write them with different EEPROM contents to see the effect from the floppy disk.Since I did not program the new 24C02's eeprom so they're brand new into the acquisition board, I've first dumped their content which was full of 1's (FFFFFF...). I guess this file content corrupts the CRC check of the TDS540C explaining the self-test partial fail.Then I've written inside the EEPROM a full content of 0's (000000...) but it still make the self-test to fail even though their CRC is zero. So it seems the TDS operating system knows that a EEPROM content full of zeros is a problem and cannot be a valid acquisition board parameters.The luck from the start, I do have another TDS540C which was always working so I've copied its EEPROM content into the failed one via the floppy disk method of @flyte. Maybe I've been lucky or miss a technical point but it looks like that I do not need to calibrate because self-test OK and SPC passed all (see attached pictures).Later I'll still build an arduino EEPROM reader to see if the previous EEPROM can be partially recovered (probably not the first one but maybe yes the 2nd one).Stay safe and healthy, Albert

author: charlyd
author_rank: Frequent Contributor
timestamp: April 03, 2020, 10:27:25 pm
content: Hi albert this looks good. so at the end.. you went the route i told you and the error is gone now, but with (wrong) cals from the other scope.i mean to say they are within the borders but a new calibration is for this scope always the best choose. what do you need just a NI GPIB card i found mine for $20 and an old PIII pc or so. assuming you have a SG to max 1Ghz . but even those are for a few $$ for sale on ebay. ( and a few corona hours , nice to do ) and when you finished you can recal the other so there or both ready for the next 20 years.but ok nice repair. what is the next project gone be …...

author: Tantratron
author_rank: Frequent Contributor
timestamp: April 12, 2020, 09:32:01 am
content: Quote from: charlyd on April 03, 2020, 10:27:25 pmThank you again @charlyd where indeed you were right from the start, the U1052 eeprom was the culprit and we might have been the only two so far publicly to get that seldom and strange Fail ++Processor.Quote from: flyte on February 03, 2020, 07:13:58 pmFor those of you interested with one solution to repair then dump the EEPROM content, after different trials this week I've fully recovered the 256 octets so the TDS540-1G does not need calibration... see conclusion herehttps://www.eevblog.com/forum/repair/attempting-repair-eeprom-voltage-increase-method/msg3011456/#msg3011456or read complete thread for the repair process using anarduino EEPROM readertool andsome solderingAlbert