TDS544A NVRAM-Content Verification

Questions in this forum area are community supported. Tektronix does not regularly monitor posts in this area.
Post Reply
Tobias Ammann
Posts: 4
Joined: March 12th, 2018, 1:59 pm
Country: Germany

TDS544A NVRAM-Content Verification

Post by Tobias Ammann » March 12th, 2018, 3:27 pm

Hello,

a couple of days ago I finished the repair of a TDS544A Oscilloscope. I got the scope from a fellow student as exchange for some beers :D . Of course, the scope was broken at this time.

It suffered from the classical leaky caps on the acquisition board. I think, I went through the "standard" repair procedure. First recap the whole thing -> search for broken traces and solder joints and so on. I started with the solder joints that looked really bad (there were quite a lot of them).

However, long story short. After quite some work I got all error messages to disappear. The Scope also passes Signal-Patch-Compensation now.

One thing I experienced throughout the repair: The ADCs and Preamps get really hot. I had to make sure to apply some extra air flow. One error message that I got repeatably if the fans were not tuned on was:

STRIGA must be high when triggered.

So, it seems that I got this error only due to to improper cooling.

The only thing left to do is to replace the DS1650Y-100 NVSRAM on the processor board. The Date code on mine is 93 - 25 Years sold impressive that the battery still holds the data. However, I am afraid that the chip might die during the desoldering process (as some users here experienced) and I do not own an EEPROM-Programmer :/.

I searched a while for the usage of tektool. I found one compiled version (tektool5) on the forum which seems to work nice even on my windows10 and my NI GPIB ENET100 Adaptor. These are the steps I have taken to make a backup of the ram:

1) Turn the scope off
2) Turn the cal switch to state ON
3) Power on the scope
4) The lights on the user control will light up, but the scope wont boot (But it will react to GPIB-Commands on Primary address 29)
5) Run the tektool5 command: tektool5 -r TDS544A_NVRAM_DS1650Y.bin -b 0x04000000 -l 0x80000
6) Turn the cal switch of state OFF
7) The scope should boot normally

Tektool5 seems to finish without a problem. But I am not sure if the memory content read by tektool5 is correct. I found 2 different start addresses for scopes with a DS1650Y (0x04000000, 0x0408000) but I have no idea which one is correct. Is there a way to check the NVRAM-Dump if it contains the right data? (see attachments) Can I write the memory content back on the new chip using tektool, too? I ordered new DS1650Y chips from china, but it will take a while until they arrive.

Many Thanks for your help. Best Regards,
holzi
Attachments
TDS544A_NVRAM.zip
Tektool5 and NVRAM binary file
(180.79 KiB) Downloaded 292 times

fenugrec
Posts: 73
Joined: January 18th, 2017, 3:51 pm
Country: Canada

Re: TDS544A NVRAM-Content Verification

Post by fenugrec » March 12th, 2018, 5:25 pm

Tobias Ammann wrote:
March 12th, 2018, 3:27 pm
One thing I experienced throughout the repair: The ADCs and Preamps get really hot. I had to make sure to apply some extra air flow.
Some other users have mentioned that you should never, ever run the Acq board without forced cooling (either in-case, with fan running, or out of case but with a sufficient fan).
Tektool5 seems to finish without a problem. But I am not sure if the memory content read by tektool5 is correct.
I took a quick look at your dump. Some pretty serious errors :

Code: Select all

** exp data= 0 actual= 1 for bit # 28 for addr: 0x72c021e
** exp data= 0 actual= 1 for bit # 27 for addr: 0x72c021e
...
acqMemAddr
** addr = 0x7300000  exp data = 0x101  actual = 0x3939
...
DAC system failure
...
acqProcThermistor <<<<<<< good hint
acq processor not responding
hopefully those aren't happening anymore ?
The rest of the dump seems reasonable, but they're hard to compare. You might try searching for someone else that has uploaded a 544A dump somewhere, either here, or other sites like ko4bb, hakanh, etc.

I found 2 different start addresses for scopes with a DS1650Y (0x04000000, 0x0408000) but I have no idea which one is correct.
In my notes, I have

Code: Select all

0x0400 0000 NVRAM DS1486 RTC, 512kB
0x0408 0000 NVRAM DS1650 NVRAM, 128kB
so you would be missing the second part, to get a complete backup.
Can I write the memory content back on the new chip using tektool, too?
Yes. (note, the original author's repo is at https://github.com/sschnelle/tekfwtool )

strick
Posts: 56
Joined: March 22nd, 2016, 11:23 am
Country: United States

Re: TDS544A NVRAM-Content Verification

Post by strick » March 14th, 2018, 1:24 pm

Tobias,
It depends on the scope generation:
if there is a DS1486 chip then:
the DS1486 is at 0x04000000 and is a length of 20000 (128k)
the DS1650/DS1250 is at 0x04080000 and is a length of 80000 (512k)

if there is just a clock chip (or no clock chip) and just the DS1650 then:
the DS1650/DS1250 is at 0x04000000 and is a length of 80000 (512k)

with a DS1486 installed, I suspect the 1650 only holds extra data, not any calibration or options data. I've seen 1650 chips that held data that was obviously junk and the scopes did fine. If the 1486 had errors, then big problems...

Strick

Tobias Ammann
Posts: 4
Joined: March 12th, 2018, 1:59 pm
Country: Germany

Re: TDS544A NVRAM-Content Verification

Post by Tobias Ammann » March 14th, 2018, 3:32 pm

Hello,
thanks for your replies.
hopefully those aren't happening anymore?
Luckily not :) I cleared the error log several times during and after the repair. The Error log stays clean now. However, the old error messages seem to persist in the NVRAM even after clearing it via GPIB (maybe they change only the pointer addresses?)
Yes. (note, the original author's repo is at https://github.com/sschnelle/tekfwtool )
It took me quite some time to get the tekfwtool compiled. First, I made the mistake trying to compile using cygwin64. But the binary file gpib-32.obj is for i386. This threw some bad linker errors. By switching to the x86 version of cygwin I managed to compile it. I had to make some changes to the source code:

1) MakeFile: change CC from "/cygdrive/c/mingw/bin/gcc" to "gcc" as I used the cygwin gcc
2) make was not able to execute the "gen-procs.sh" script, I had to do it manually
3) target-procs.h: There where newlines between #define and the constant. I had to remove them manually
4) tekfwtool.c: #include <errno.h> was missing

So many changes do not make me confident :? I attached a screenshot of the compilation.
f there is just a clock chip (or no clock chip) and just the DS1650 then:
the DS1650/DS1250 is at 0x04000000 and is a length of 80000 (512k)
As I can not find a DS1486 on my processor board i assume that 0x04000000 is the correct start address. I have only a DS1286 beside the DS1650Y.

I did a more extended search for a NVRAM dump of another scope to compare. I think it was strick who uploaded it, thanks!. There are a lot of differenced between his and my file. Some parts seems to be identical (the "Flash Rom ID is bogus!" string at the beginning of the file).

After that i made a read with the new compiled tekfwtool from address 0x04000000. And guess what the files are also slightly different! The numbers after "Flash Rom ID is bogus!" string at the beginning has changed. I added the new files as an attachment.

I have no idea where these changes come from or if I can trust my dump files now?

Many Thanks for your opinions
Tobias
Attachments
cpu_board.jpg
cpu_board.jpg (484.6 KiB) Viewed 5120 times
compile.png
compile.png (25.38 KiB) Viewed 5124 times
544A_NVRAM.zip
(471.45 KiB) Downloaded 284 times

fenugrec
Posts: 73
Joined: January 18th, 2017, 3:51 pm
Country: Canada

Re: TDS544A NVRAM-Content Verification

Post by fenugrec » March 14th, 2018, 9:03 pm

Tobias Ammann wrote:
March 14th, 2018, 3:32 pm
1) MakeFile: change CC from "/cygdrive/c/mingw/bin/gcc" to "gcc" as I used the cygwin gcc
2) make was not able to execute the "gen-procs.sh" script, I had to do it manually
3) target-procs.h: There where newlines between #define and the constant. I had to remove them manually
4) tekfwtool.c: #include <errno.h> was missing
1) that's entirely expected
2) indeed, it's meant to be run in a bash shell . It might work in MSYS but that's another heap of problems.
3) that is probably due to how you manually ran gen-procs - note, that step compiles the reflashing kernel and has no impact on NVRAM access. In fact, I compiled tekfwtool entirely without reflashing support under DOS .
4) that's a good find - I'm not sure why, but MS C compiler v6 didn't even notice ! I've gone ahead and submitted a patch for this.

The Warnungs im Deutsch about format specifiers should also be looked at, but I'm pretty sure they won't brick your scope.
So many changes do not make me confident :?
Well, let's take one step back - your scope doesn't work, it cost you nearly nothing; you're not touching the main ROM; and you're definitely not the first to use tekfwtool. I don't think you're risking much at this point... But you get 10 points for being careful.

I have no idea where these changes come from or if I can trust my dump files now?
the firmware uses NVRAM in a non-trivial way. Almost nothing in it has a fixed location, so comparison can be difficult. Also as @strick mentioned, part of the dump is the clock for example.
Dumping NVRAM is not very long, if you dump it twice in a row, I would expect nearly identical results. Note, tekfwtool only sends and receives GPIB commands which have a basic checksum. If those go through OK with no corruption, the rest is determined entirely by the scope firmware which takes care of reading the NVRAM. My random internet stranger opinion is : don't worry about it *unless* the scope complains about NVRAM corruption.

Tobias Ammann
Posts: 4
Joined: March 12th, 2018, 1:59 pm
Country: Germany

Re: TDS544A NVRAM-Content Verification

Post by Tobias Ammann » March 15th, 2018, 12:00 pm

Hi,
your explanations for my compiling steps sound reasonable. Both of the german warnings tell that the format string specifier "%l" is unknown. Maybe it should be "%ld" for variables of type long? But as you told this is not a serious issue so I don´t care.
Well, let's take one step back - your scope doesn't work, it cost you nearly nothing
Hmm, actually it is working right now (until the battery of the DS1650Y fails). I spent quite a lot of hours fixing it, so it would be sad if i brick the device. But you are right. It is just a hobby :D
if you dump it twice in a row, I would expect nearly identical results.
I tried it and indeed the dumps are nearly the same. Thanks for your help, I think I will wait now for the DS1650Y to arrive from china.

best regards
Tobias

Tobias Ammann
Posts: 4
Joined: March 12th, 2018, 1:59 pm
Country: Germany

Re: TDS544A NVRAM-Content Verification

Post by Tobias Ammann » April 9th, 2018, 11:49 am

Hi,
the dallas NVRAM-Chips arrived a view days ago. I removed the chip and replaced it with a ic-socket as adviced by some people here in the forum. My Dallas 1650Y survided the desoldering process. The write back of the ram content with tekfwtool went also well. So many thanks for your help and the great tool!! :D

I attached my compiled tekfwtool.exe, the nvram binary file (with option 2F and 1M) and a screenshot of the commands used. Maybe this will help someone in the future. Firmware: v3.7e
Attachments
NVRAM_TDS544A_1M_2F.zip
(182.25 KiB) Downloaded 257 times

Post Reply

Return to “Other or Discontinued Oscilloscopes”

Who is online

Users browsing this forum: No registered users and 3 guests