Tek TDS 744A/784A FWs: nvLibrariansDiag, Libs with crcc failures: , ExtConst

[mssbid]

After fixing my 744A I decided to play with FW updates. I went from 1.0.1e to 1.1e
and all was fine. After going to 4.2.1e I encountered the error:

nvLibrariansDiag, Libs with crcc failures: ,  ExtConst"

As we can read elsewhere this is due to a different location of various cal stuff which
sits in the NVRAM. This probably could be fixed by running the entire cal procedure.

Is there a list of FWs which exist at all for the 744A (784A) and which are "compatible"
regarding the NVRAM layout?

[TERRA Operative]

I have been uploading all firmwares I encounter to the tekwiki.
(If anyones finds any versions not there on tekwiki, please copy it out of your scope for me! Instructions here )

https://w140.com/tekwiki/wiki/TDS744

https://w140.com/tekwiki/wiki/TDS784

I believe you can't go up or down a major revision level (i.e V1.x to V4.x etc) due to physical differences in the hardware.
I'm not 100% sure what the actual lines of incompatibility are, but it seems to be this way. There is definitely incompatibilities with new and old hardware regarding old and new firmware.

[charlyd]

i posted a very big list in an other topic a while ago

[mssbid]

I believe you can't go up or down a major revision level (i.e V1.x to V4.x etc) due to physical differences in the hardware.
I'm not 100% sure what the actual lines of incompatibility are, but it seems to be this way. There is definitely incompatibilities with new and old hardware regarding old and new firmware.

Well, my understanding is, that you can't use 744A fw on 744B/C/D. And 744C fw on 744A/B/D. And so on.

But on 7x4A you _can_  use 1.x as well as 4.x from a hardware point of view (but no [567].x as these are
for different hardware).

However, in order for 4.x to work on a 7x4A which had 1.x before (or vice versa), this ExtConst thing has
to be fixed, e.g. by a complete calibration. When I tried that 4.2.1e on the (former 1.0e) 744A, this
error was the only one. All other diag tests where passed perfectly. Additionally, the scope seemed
to work. I did not verify all combination of settings but all 4 channels with a few att and timebase
settings. I assume that it used some default values which were not to far away.

I also found an NVRAM dump where the name suggested that it is for a 744A running 4.2.1e. Knowing
that its cal data won't be the correct ones for my 744A, it tried it and received the same error (and only
this error) again.

If someone has a 744A with a 4.x fw and definitely does not encounter the ExtConst error when running
diagnostics, I would be interested in his NVRAM dump. Of course this is just for testing as the cal values
won't be correct as well...

[mssbid]

i posted a very big list in an other topic a while ago

https://www.eevblog.com/forum/testgear/tds754d-fail-processor/msg2869574/#msg2869574

But it does not mention the compatibility and I can't find 1.0.1e (which was on my 744A)
and 1.1e (which is on my 784A).

[fenugrec]

nvLibrarian should be related to the NVRAM, i.e. not the EEPROM on the Acq board which is the one you really don't want to lose. NVRAM should only hold SPC and other easy-to-repeat calibrations ?

Have you tried (after a backup) clearing NVRAM entirely then rebooting ?

[mssbid]

nvLibrarian should be related to the NVRAM, i.e. not the EEPROM on the Acq board which is the one you really don't want to lose. NVRAM should only hold SPC and other easy-to-repeat calibrations ?

From what I've learned here, the 744A does not have Acq EEPROMs and indeed
has its factory cal data in the NVRAM.

Have you tried (after a backup) clearing NVRAM entirely then rebooting ?

Nope, see above. But I've run SPC with flying colours and the error did not go away.

Edit: When time permits :-), I wanted to check where the FW expects to see that
ExtConst data in the NVRAM and if 1.x and 4.x use the same layout. Then it might
be possible to move that block within the NVRAM and after fixing the CRC all could
be fine. I've been pretty good in 68k assembler 30 years ago (good old Atari times :-))
so the only thing I need is time. I also found your interesting posts on

https://www.eevblog.com/forum/testgear/tds-744a-(-friends)-firmware-reverse-engineering/msg1424907/#msg1424907

Do you have some kind of dissassembly which you are able to share (so i do not
have to start from scratch)?

[fenugrec]

From what I've learned here, the 744A does not have Acq EEPROMs

I assure you, my 744A has both U1052 and U1055 EEPs on the acq board. Do some later 744A units not have them anymore ?

Nope, see above. But I've run SPC with flying colours and the error did not go away.

Yeah, I would still suggest try clearing the NVRAM - the XYZ-librarian functions look up stuff in there according to a certain layout, which they normally won't modify. Based on what I remember from disassembling them a while ago... a blank NV should trigger a reconstruction of the basic structures in there.

If you're curious you could try my nvram_tool.c utility (from https://github.com/fenugrec/tdsutils ) against a dump of your NVRAM, it should show some of the contents and checksums, but that wouldn't help you much.

Do you have some kind of dissassembly which you are able to share

I'd have to export the db from IDA, I don't think I ever migrated that project to ghidra... I'll see what I can do. But really, I have my money on clearing NVRAM. Worry about transferring constants later...


Anyway, here's part of my shorthand RE notes regarding NVRAM layout corresponding to fw 1.1e :

Code: [Select]

*********** NVRAM
see nvram_tool.c
MAP
400 0000, siz = 0x10 : RTC
400 0020, siz = E0 : bootLineBottom, magic 0xE1A0C4D1; end= 400 0100
400 00E4 : first bytes of  _checkNVStorage func , wtf ?
400 0100, siz = 0x700 : "kernel exception log" ? confirm with bootrom; end = 400 0800
400 0100, siz = ? "_sysExcMsg", for _printExc; entire NVRAM area ?

400 1BF0, sparse : see _LibraryStateAddresses .idata
400 9506, siz = 1BCE (_pu_diagFRUseq?, also _scopeErrorLogInit etc), end = 400 b0d4
400 b0d4, siz = 7FFE (_pu_diagFRUseq?), end= 401 30d2
400 b0d4, siz = 7F328 (_clearCycleRoomErrorLog), end = 408 a3fc (hmm spill into 408xxxx)

log entries : {
u32 timestamp;
dchar errno[]; //printf("%d", errno)
dchar errstr[];
}
dchar is ASCII generated by putBuffer; can add 0xFF padding on trailing byte to do u16 writes to nvram)

struct _scope_error_table {
u32 pstring
u16 typ? //+4 , maybe loglevel
u32 pstring2; //+6 , sometimes 0
u16 flagsA //+A
u16 flagsC //+C mask / bitfield, check against loghdr.fieldA
u32 flags2
}


Can't really help with the finer details, as I haven't looked at this firmware in a few years.

[mssbid]

I assure you, my 744A has both U1052 and U1055 EEPs on the acq board. Do some later 744A units not have them anymore ?

I didn't look exhaustively yet -- I had my eye on replacing the two dallas chips and fixing
a cold solder joint on the interconnect board of the 744A. But I've read a lot here and in
the Tek forum and the outcome was that only B/C/D models have them.

And I can't look right now as the units are currently approx 5000 km away from me :-).
FWIW,  I have the product numbers of the boards:

744A: 671-3461-03
784A: 671-3740-00

Do you have your number(s) at hand?

Yeah, I would still suggest try clearing the NVRAM - the XYZ-librarian functions look up stuff in there according to a certain layout, which they normally won't modify. Based on what I remember from disassembling them a while ago... a blank NV should trigger a reconstruction of the basic structures in there.

Well I can try that when I am back. But first I'll check if there are really
any EEPROMs. If yes, I will first remove them and make a copy.

Can't really help with the finer details, as I haven't looked at this firmware in a few years.

Don't worry -- I still have no idea when I will find the time to dig further into this. Thanks
for the link to your tools.

[fenugrec]

the Tek forum and the outcome was that only B/C/D models have them.

Well it's the first time I hear that, anyway. I also remember seeing eeprom read/write funcs in the 1.1e firmware - not sure how it's handled though, is the I2C bus routed all the way to the main board or is it managed via the huge gate arrays....
Also haven't compared to other fw versions; seems like a pretty substantial change that would warrant more than just a minor version bump.

I only have a photo of my acq board and the sticker is nearly unreadable, tweaking the colors to the max I would say 679-3739-01 .

[mssbid]

the Tek forum and the outcome was that only B/C/D models have them.

Well it's the first time I hear that, anyway.

Hmm, I didn't record the links but it was stated in several places. In the end it doesn't
matter -- I will have to check the boards when I'm back.

[mssbid]

the Tek forum and the outcome was that only B/C/D models have them.

Well it's the first time I hear that, anyway.

FWIW, here is one of the posts:

https://www.eevblog.com/forum/testgear/tektronix-tds500600700-nvram-floppy-dump-tool/msg2428782/#msg2428782

There are more but I am too lazy to search for them :-).

[mssbid]

From what I've learned here, the 744A does not have Acq EEPROMs

I assure you, my 744A has both U1052 and U1055 EEPs on the acq board. Do some later 744A units not have them anymore ?

It seems you are right: I didn't open my 744A for checking but simply ran tdsNvramMinimalFloppyDumper
and it spit out a 512 bytes file which perfectly passes all checksum checks:

Code: [Select]

bali:~>java -cp TDSNvrCV_2_1.jar TDSNvramChecksumVerifier ~/x/ACQEEPRM.BIN
TDSNvramChecksumVerifier v2.1
 
Read 512 bytes of dump data from /people/andre/x/ACQEEPRM.BIN
 
Detected small file, considering dump an ACQUISITION EEPROM dump
 
Dump data matching firmware prototype acqEEPROM-TDS784D-v7.4e_TDS784C-v5.2e, all known checksums found VALID
 
Interpretation of dump data as a firmware acqEEPROM-TDS784D-v7.4e_TDS784C-v5.2e based dump :
dump section=ACQEEPROM address=0xa size=0x1ce checksum=OK (actual=0xf146 computed=0xf146)

So it really seem to have those two EEPROMs ;-). I will do the same on my 784A later...

BTW, in addition to my previous post, here is an excerpt from the info.txt that comes
with tdsNvramFloppyTools_v5:

Code: [Select]

...
Dumps the contents of the calibration constants 24C02 EEPROMs located
on the acquisition boards of the -B, -C and -D series scopes, to a file.
-A series scopes have no such EEPROMs on the acquisition board and
store these constants in regular NVRAM, albeit in a hardware-protected
region.
...

As we have learned now, this might be true but at least for my (and your) 744A it is not.

So when time permits, I will follow your suggestion and clear the NVRAM after loading
the 4.2.1e FW and see what happens.

BTW, is there a simple way to clear it? Or should I simply write a 128kB file with zeroes
using tektool?

[mssbid]

This to confirm that my 784A also has the two EEPROMs (confirmed visually and by reading
their content using tdsAcqEEPROMMinimalFloppyDumper).

So the statement that these EEPROMs only exist on -B and higher model is not true -- at
least not for the 744A and 784A using the Acq Boards 671-3461-03 and 671-3740-00.

[mssbid]

nvLibrarian should be related to the NVRAM, i.e. not the EEPROM on the Acq board which is the one you really don't want to lose. NVRAM should only hold SPC and other easy-to-repeat calibrations ?

Have you tried (after a backup) clearing NVRAM entirely then rebooting ?

Tried that now. I flashed FW 4.2.1e again and uploaded a file containung 131072 zeroes in
order to clear the NVRAM. Settings, SPC and date were reset. I did a SPC which succeeded.
However, the error

nvLibrariansDiag, Libs with crcc failures: ,  ExtConst"

remains...

[fenugrec]

However, the error
nvLibrariansDiag, Libs with crcc failures: ,  ExtConst"
remains...

Interesting.

To state the obvious... you tried a factory reset from the scope menus ?

.... a few minutes later....

 ah. I got curious, loaded up ghidra and my notes,

 I'm trying to think how you could get the following function to run, which should reset the extended cal librarian... maybe from the service console, or with a modified version of the the special nvram_dump floppy ?

Code: [Select]

void _loadFactoryValuesIntoExtendedCal(void)

{
  _libLoadInitValues(&_extendedCalLibrarian);
  return;
}


Incidentally, here's my take on the "librarians".
First, a list of the librarian "descriptors" :

Code: [Select]

                             _libId                                          XREF[3]:     _nvLibrariansDiag:011f0c78(R),
                                                                                          _calLibrarianDefaultCk:011f0d3e(
                                                                                          012b172e(*) 
        050176d4 01 19 a3 cc     addr       _extendedCalLibrarian                            = 0119a0f8
                             PTR__calConstantLibrarian_050176d8              XREF[2]:     _nvLibrariansDiag:011f0c78(R),
                                                                                          _calLibrarianDefaultCk:011f0d3e(
        050176d8 01 19 9e 10     addr       _calConstantLibrarian
        050176dc 01 19 92 bc     addr       _scopeStateLibrarian
        050176e0 01 19 a0 d4     addr       _environmentLibrarian
        050176e4 01 19 a4 ee     addr       _diagLibrarian
        050176e8 01 19 a4 9a     addr       _hwAccountantLibrarian                           = 0119a3f0

Let's see what's in "_extendedCalLibrarian" :

Code: [Select]

                             _extendedCalLibrarian                           XREF[11]:    _loadFactoryValuesIntoExtendedCa
                                                                                          _verifyExtendedCalCheckSum:01196
                                                                                          _verifyExtendedCalCheckSum:01196
                                                                                          _invokeExtendedCalStartupFunctio
                                                                                          _verifyLibExtendedCalCheckSum:01
                                                                                          _saveExtendedCalLib:011972b2(*),
                                                                                          _saveExtendedCalLib:011972c2(*),
                                                                                          012ae8ea(*), 05013f84(*),
                                                                                          05013f8c(*), 050176d4(*) 
        0119a3cc 01 19 a0 f8     addr       _extendedCalLibrarian_type                       = 02h
        0119a3d0 01 19 a1 1e     addr       _extendedCalLibrarian_size
        0119a3d4 01 19 a1 6a     addr       _extendedCalLibrarian_offset
        0119a3d8 01 19 a2 02     addr       _extendedCalLibrarian_factory                    = 07h
        0119a3dc 05 03 91 8a     addr       DAT_0503918a
        0119a3e0 00 00 01 ca     ddw        1CAh
        0119a3e4 00 00 01 ca     ddw        1CAh
        0119a3e8 00 26 00 04     ddw        260004h
        0119a3ec 01 19 6b 32     addr       _libVerifyExtendedCal

Ok, nothing very interesting, but digging around more in my notes I found the missing link:

Code: [Select]

                             _indirectLibHandles                             XREF[6]:     FUN_01196dbe:01196ddc(R),
                                                                                          _recallAllLibs:01197208(R),
                                                                                          _saveAllLibs:01197242(R),
                                                                                          _saveAllButExtAndHWALib:0119727c
                                                                                          _libMonitor:01197310(R),
                                                                                          012b0912(*) 
        05013f84 01 19 a3 cc     addr       _extendedCalLibrarian                            = 0119a0f8
                             PTR_s_EXTCAL_05013f88                           XREF[2]:     _saveLib:01197018(R),
                                                                                          _libMonitor:0119733e(R) 
        05013f88 01 19 73 f2     addr       s_EXTCAL_011973f2                                = "EXTCAL"
        05013f8c 01 19 a3 cc     addr       _extendedCalLibrarian                            = 0119a0f8
        05013f90 01 19 74 a6     addr       _gtlX24c02Bcopy
        05013f94 01 19 76 62     addr       _gtlX24c02Bcmp
        05013f98 05 03 91 88     addr       _extCalRamLib

See those _gtlX24c02* functions : they talk to the serial EEPROMs on the acq board ! So there's a level of indirection when some functions call for e.g. "check librarian checksums", the backend would run these functions to read and write data.

So maybe it's not the NVRAM you should be erasing, but instead maybe the EEPs ? Of course making 1000% sure you have a good backup... what I did once was to sniff the I2C bus with an LA to double-check the contents matched what I got via GPIB.
Or, write something to those EEPs that is taken from a known-working 4.2.1-based scope ?. Maybe the contents is structured differently. It would make sense that the "factory reset" from the scope UI wouldn't trash that data, since it's quite more critical than e.g. SPC consts.

[mssbid]

To state the obvious... you tried a factory reset from the scope menus ?

Sure. Well I did that Secure Erase (or how it's called).

So maybe it's not the NVRAM you should be erasing, but instead maybe the EEPs ? Of course making 1000% sure you have a good backup... what I did once was to sniff the I2C bus with an LA to double-check the contents matched what I got via GPIB.

Well, I am pretty sure to have good backups. I read it first with the floppy tools
(several times) and then with getcaldata via GPIB. Files were always the same
and survived that checksum test.

BTW, on the 784A this worked immediately. On the 744A getcaldata produced
only 2 files containing only zeroes (I remember I've read that other people had
this as well). I started NI Spy and found the following:

getcaldata sends e.g., WORDCONSTANT:ATOFFSET? 262144,0 to the scope.
It then reads 6 bytes containing the corresponding word. For some reasons
the 744A answered something similar to:

:WORDCONSTANT:ATOFFSET? 262144,0,xyz

with xyz being the desired word value. Since getcaldata couldn't convert ":WORDC"
to any meaningful integer, it produces only files containing zeroes. When sending

WORDCONSTANT:ATOFFSET? 262144,0

manually with the NI tool, only xyz came back (as expected). So I started to play with
the adapter settings but nothing changed. But after clearing the scope's error log
it suddenly worked. No idea why...

Or, write something to those EEPs that is taken from a known-working 4.2.1-based scope ?. Maybe the contents is structured differently. It would make sense that the "factory reset" from the scope UI wouldn't trash that data, since it's quite more critical than e.g. SPC consts.

Although I have probably good EEPROM backups I am still scarey to write them.
However, I have ordered some 24LC024 I/SN a few days ago since I wanted to
be prepared if my old EEPROMs fail one day. After having a physical and working
backup, I might dare to try this ;-).

Thanks for your ghidra stuff. Maybe I'll dig into this code one day when time permits...

[mssbid]

OK, some more about playing with the EEPROMs on the 744a:

1. Removed the two X24C02 EEPROMs. Read them with a programmer and compared
the results with the data from getcaldata and tdsAcqEEPROMMinimalFloppyDumper
All OK.

2. Soldered two self- made DIP/SOIC adapters to the ACQ board (see pic). Now we can
swap chips easily.

3. Wrote the content to two new 24LC024 chips and inserted them.

4. Booted with 4.2.1e:
ERRORID: 153 diagnostic test failure extended cal librarian reset

5. Removed the chips and booted 4.2.1e again:
ERRORID: 346 nv storage too small more bytes requested than availabl-e>
0x51ffea8 (tRootTask): libError 346, lib EXTCAL, id=346, msg=more bytes requested than available

6. Inserted two empty chips and booted 4.2.1e again:
ERRORID: 153 diagnostic test failure extended cal librarian reset
(same as in step 4).

7. Downgraded the scope to 1.1e (where we came from). Inserted the properly
programmed 24LC024 chips. Ran complete diagnostics. No errors.


What have we learned so far?

a) 24LC024 work as a replacement for the X24C02.

b) Empty EEPROMs don't get initialised with whatever defaults


Repeating my request:

If anyone has a 744a or a 784a with FW 4.xx (or 2.xx or 3.xx) and has no diag
errors, please send me your EEPROM content. This can easily be obtained with
tdsAcqEEPROMMinimalFloppyDumper or getcaldata (getting the dumps is recommended
anyways).

[charlyd]

hi i can asure you that installing good empty eeprom 24C02 will work on a TDS754D solving the [250 nvstorage too small more bytes requested than available] but the unit needs to be recalibrated to get back triple PASS .

[mssbid]

hi i can asure you that installing good empty eeprom 24C02 will work on a TDS754D solving the [250 nvstorage too small more bytes requested than available]

No need to assure me as I didn't say anything different. I wrote:

Code: [Select]

5. Removed the chips and booted 4.2.1e again:
ERRORID: 346 nv storage too small more bytes requested than availabl-e>
0x51ffea8 (tRootTask): libError 346, lib EXTCAL, id=346, msg=more bytes requested than available

and

Code: [Select]

6. Inserted two empty chips and booted 4.2.1e again:
ERRORID: 153 diagnostic test failure extended cal librarian reset
(same as in step 4).

so the "too small" message appeared WITHOUT any EEPROMs and changed
into "cal librarian reset" after installing two blank ones.

The whole thread is about switching from FW 1.1e to 4.2.1e. Regarding my 744A and 784A
I have learned now, that

1. In contrary to what has been stated in a lot of places, there are A-type devices which
have these EEPROMs on the ACQ board.

2. The "precious" cal data is in these EEPROMs and not in the Dallas chip(s).

3. Therefore one can erase the Dallas content and will only lose options and SPC and
the date.

4. The X24C02 can be replaced by 24LC024 (and probably others).

5. The data in the EEPROMs is compatible when going from 1.0.1e to 1.1e but not from
1.1e to 4.2.1e.

6. One probably can get rid of this when doing a full recal. I can't do this so I will stay with
1.1e for the time being.

Two confirm this, I am interested in trying any(!) EEPROM content from any 744A with a
FW 4.2.1e.

[charlyd]

what i can tell about FW and exchange them between same unit models.  this can be tricky  for example  there is a TDS784D but this scope has a least two different models ACQ board and those FW versions are not interchangable. and i can image that there are more models with the same situation.

somewhere on this forum i posted a very big list of all FW version of the TDSxxx and there belonging models. 

[mssbid]

what i can tell about FW and exchange them between same unit models.  this can be tricky  for example  there is a TDS784D but this scope has a least two different models ACQ board and those FW versions are not interchangable. and i can image that there are more models with the same situation.

Might be, of course. This is why I'd like to have an EEPROM dump of anybody with a 744A/784A
who runs 4.x and has no diag errors.

somewhere on this forum i posted a very big list of all FW version of the TDSxxx and there belonging models.

Yep, I found this list (may I ask: where did you get it from?).

[hvontres]

what i can tell about FW and exchange them between same unit models.  this can be tricky  for example  there is a TDS784D but this scope has a least two different models ACQ board and those FW versions are not interchangable. and i can image that there are more models with the same situation.

Might be, of course. This is why I'd like to have an EEPROM dump of anybody with a 744A/784A
who runs 4.x and has no diag errors.

I don't have the setup for dumping my EEPROMS yet, but I can confirm that even a partial calibration of a 744a with 4.2.1e removes the nvLibrariansDiag Errors from the Error log. I am asuming that if there are no errors, the self test simply re-boots the scope without showing the results? Sorry, this is my first TDS 7xx and it came with 4.2.1e already on it, so I have no idea what correct operation is supposed to be like.

Once I can get the rest of the cals to pass (my DIY reference setup struggles with the 20ma step during the 50 Ohm gain step and my cheap RF amplifer appears to be dead, so I can't do the HF cals yet either) I will try to dump the EEPROMS for you.

[mssbid]

Once I can get the rest of the cals to pass (my DIY reference setup struggles with the 20ma step during the 50 Ohm gain step and my cheap RF amplifer appears to be dead, so I can't do the HF cals yet either) I will try to dump the EEPROMS for you.

Cool, thanks a lot in advance!

[hvontres]

Once I can get the rest of the cals to pass (my DIY reference setup struggles with the 20ma step during the 50 Ohm gain step and my cheap RF amplifer appears to be dead, so I can't do the HF cals yet either) I will try to dump the EEPROMS for you.

Cool, thanks a lot in advance!

Quick update: I managed to get my Gpib setup working enough to clear the error logs, and indeed, the nvLibrarians errors are gone.