Attempting repair of TDS540C - Option 1G - Fail Processor

[Tantratron]

I ask you again: Have you programmer for EPROM  (TL866 and other type) ?
Yes, heat  solder iron  and desolder  NVSRAM   (or: use tekfwtool)

Nope 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 thread https://www.eevblog.com/forum/repair/gpib-usb-control-between-macbook-air-(macintosh)-and-tds540c/msg2836360/#msg2836360

Hello 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 ++PROCESSOR

Maybe somebody has other idea or suggestion on how to repair this TDS540C 

[Tantratron]

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 Option EDIT:  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.

Hell 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 ++Processor

Amicalement, Albert

[Tantratron]

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 failed Serial B010811

Processor board S/N 9740L
DS1486-120 9735H
DS1650Y-100 9716U
flashfile E28F016SA
Firmware V5.0.1e

Acquisition board S/N 9745D
EEPROM X24C02

TDS540C-2G working Serial B010489

Processor board S/N 9724A
DS1486-120 9723H
DS1650Y-100 9650H
flashfile E28F016SA
Firmware V5.0e

Acquisition board S/N 9810G
EEPROM X24C02

As 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 failed https://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

[shakalnokturn]

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.

[madao]

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.

greetings
matt

[Tantratron]

I ask you, have you checked,  2Gs/s per channel?

It confirm  failed 24c02.

How 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 ?

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.

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

[madao]

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. 

Greetings
matt

[Tantratron]

I mean: Did you checked,  did good acquisition  board runs in failed TDS540C  up to 2Gigasamle /s per channel? (max 2 Ch active)

Yes your resistor modification to hack from 1GS/s to 2GS/s has worked very good, see https://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2856924/#msg2856924

Of course this does not solve the fail ++Processor 

[madao]

ops, mistaking.

I asked you , did  good acquisition board run in TDS540C with 1G-option  up to 2 Gs/s.

[Tantratron]

ops, mistaking.

I asked you , did  good acquisition board run in TDS540C with 1G-option  up to 2 Gs/s.

Good 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 ago 

Similar to option 13, if there is RS232-Centronic board then TDS banner shows Option 13 otherwise it will not

[Tantratron]

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.

I do not understand what you are asking here, please explain with more details ?

Both NVRAM's are on processor-display board, see again my post https://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2860746/#msg2860746 describing both TDS540C's

[Tantratron]

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.

As 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

[madao]

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.

I do not understand what you are asking here, please explain with more details ?

Both NVRAM's are on processor-display board, see again my post https://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2860746/#msg2860746 describing both TDS540C's

Again !  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)

[Tantratron]

Again !  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)

Hello 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

[shakalnokturn]

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.

[Tantratron]

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.

Thank 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 thread https://www.eevblog.com/forum/repair/tekfwtool-for-tds540c-firmware-upgrade/msg2861266/#msg2861266

What is left and open case concerns the possibility to dump-save then write-flash the X24C02 EEPROM where there is software updated in this repository https://github.com/ragges/tektools but 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 programmer

Merci, Albert

[Tantratron]

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 memories

Attached 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

[Tantratron]

Hello again,

I've now dumped the content via the GETCALDATA software https://github.com/ragges/tektools/tree/master/getcaldata of 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

[shakalnokturn]

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.

[Tantratron]

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 see https://github.com/ragges/tektools/tree/master/tdsNvramFloppyTool on edit/uptate 4

Wether 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 application https://github.com/ragges/tektools/tree/master/getcaldata

So 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

[madao]

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.

[Tantratron]

It would be interesting and helpful to see if CHARLYD finally solved his Fail ++Processor where his post https://www.eevblog.com/forum/testgear/tds754d-fail-processor/msg1319802/#msg1319802  shows the same error log as the one I'm suffering

Later CHARLYD received the new EEPROM solving part of the issue https://www.eevblog.com/forum/testgear/tds754d-fail-processor/msg1340838/#msg1340838 but not sure of his oscilloscope was finally repaired.

[charlyd]

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

[ragge]

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

So 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

[charlyd]

yep that s right of course full recal is needed.
latest FW for : TDS540C,F/W,5.3
 

and many versions listed
https://www.eevblog.com/forum/testgear/tds754d-fail-processor/msg2869574/#msg2869574