Tekfwtool for TDS540C firmware upgrade

[Tantratron]

Only C & D Serie: base address of DS1650 (nothing important) is 0x480 0000.

I think you meant 0x408 0000 but maybe I'm wrong ?

[madao]

Only C & D Serie: base address of DS1650 (nothing important) is 0x480 0000.

I think you meant 0x408 0000 but maybe I'm wrong ?

You're right. !

[ragge]

i wouldn't recommend  fixing of   base-address in erase commando, because people must type base adress to conform of erase.

@ragge. Only  28F008SA can't full/bulk-erase. 16x block erase with incrementing of block address is neccesary.

@albert,   tekXtool ist  nice name, we would christen this project with "tekXtool".

I write few notice:  ALL  Serie (whatever letter)  have baseaddress 0x100 0000 for firmware and  0x400 0000 for NVSRAM.
But mapping of NVSRAM above all serie is not same. 
All except A-Serie have frist 128kb (lenght 0x2 000) on 0x400 0000 for important NVSRAM (DS1245 or DS1486).
A-Serie have frist  512kb (lenght 0x8 0000) on same base adress for important NVSRAM (DS1650/1250)
Only C & D Serie: base address of DS1650 (nothing important) is 0x408 0000.
B-Serie, i didn't know, but i wouldn't wondering,if is same as  C&D Serie.

side (also important notice):  600C Serie is more same with 500/700D Serie.

I have telling albert, i didn't know address of  EEPROM on acquisition board.

Greetings
matt

Matt,

Thanks for all the information!
The kinds of chips and addresses I suppose should mainly depend CPU board model. I have no clue how many different versions there are, more than that there are at least 68020 and 68040 versions.

Albert and I discussed putting this kind of information publicly somewhere, preferably in a way so that anyone could contribute with information from their instrument(s).

Regards,
Ragnar

[madao]

Correct, it is more depent of CPU Board as instruments.   I have a  TLS216 with newer CPU Board (it have 28F008SA) Normally, TLS216 has older CPU Board with 28F020 (12 pieces) flash.   I have checked flash_identify function of tektool.c on this instrument.  Result is expectelty.



All  flash in this family let identify after write unified byte pattern. This  is good for unified  tool.

[Tantratron]

hello again Ragnar,

Maybe you have not noticed this specific thread where this is the last update https://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2860746/#msg2860746

I might consider to sacrifice this other TDS540C which would cost too much to repair versus looking for another TDS model. Anyway if I have some time this week plus the key fact I use Macintosh, I'll try to jump into this test since both of my TDS540C host E28F016SA flashfile chip memories set. My intent is to have the test done with tekfwtool or let's say a unified tekXtool global application.

Amicalement, Albert

Hi Albert,

That would be great!

I am quite confident that we could get it working again even if there are bugs in the current versions of tektool and tekfwtool in the repository, with some cooperation we should be able to find the bugs and fix them.

Regards,
Ragnar

Good evening Ragnar,

Proud and happy to confirm that your new tekFWtool repository first compiled then run on my MacBok Air has successfully erased the flashfile E28F016SA of my TDS540C to remove V5.0.1e then flashed v5.2e firmware.

I'm using a GPIB-USB-HS interface of National Instruments between my Mac and the TDS540C, I have no Agilent GPIB-USB to test unfortunately but recommend to use NI interface because many libraries exist for Apple.

Please attached screenshot and pictures, the erase then flash took less than 15 minutes with Mac running under OS Sierra.

Amicalement, Albert

[ragge]

Proud and happy to confirm that your new tekFWtool repository first compiled then run on my MacBok Air has successfully erased the flashfile E28F016SA of my TDS540C to remove V5.0.1e then flashed v5.2e firmware.

I am happy to hear that, thank you very much for testing!

Best regards,
Ragnar

[madao]

Hi

I have also compiled your clean up  tekfwtool.c. It looks good, but i can't programming it.
Device is CPU Board w  28F160S5.

You can replacing  "#include malloc.h" by  #define LITTLE_ENDIAN 1
I have moved   if-defined-bloc (Win32) above  if-define-bloc for MS-DOS, or else compiler make error
(of coruse, LITTLE_ENDIAN define came later than  tekfwtool.h )

I have a guess, minGW compiler didn't good their job, special  target.bin

greetings
matt

[Tantratron]

Hi

I have also compiled your clean up  tekfwtool.c. It looks good, but i can't programming it.
Device is CPU Board w  28F160S5. (Attachment Link)

You can replacing  "#include malloc.h" by  #define LITTLE_ENDIAN 1
I have moved   if-defined-bloc (Win32) above  if-define-bloc for MS-DOS, or else compiler make error
(of coruse, LITTLE_ENDIAN define came later than  tekfwtool.h )

I have a guess, minGW compiler didn't good their job, special  target.bin

greetings
matt

Hello Matt,

This afternoon when I test the programs update of Ragge, I did compile with success then run the erase with tektool but did not like the fact many displays, scrolling so I lost the track. So I thought to rather compile and run tekfwtool which is crystal clear concise as you saw in my previous post picture.

No idea who is faster, better but from my point of view, I really prefer tekfwtool.

Do you know what is the latest firmware for C series... v5.0e v5.2e or more recent for TDS540C

By the way, maybe I'll try to purchase a serie D later but for the moment, I'll secure the NVRAMs copy, the firmware copy and hopefully the EEPROM copy because my NVRAMs are very old circa 1996 and 1997. Need to decide where to buy new NVRAM kit plus purchase special pump-desoldering device to remove the 32 pins without destroying the multi-layer PCB.

[madao]

last firmware for C serie.  No i didn't know. 5.2 is newest, what i found.
Newest firmware for D serie is 7.4 and 6.6.  Important notice:  6.6 and 7.4 not interchangable, too difference acquisition board.

tekfwtool is for me useless, this a fact.  I stop to trying with tekfwtool.c. No mood anymore.  I could try it later.

Now , i am going own way with tektool.c.     I am a friends of KISS-principle.
I don't see scrolled display as a problem, a minor code modification solves problem :-)

printf( \r) instead printf( \n)

Desoldering & multi layer,   you must trying at first with scrap-PCB.
I say you, it is a bit easy to desoldering, because their solder joint is big, many space between pin and hole.


greetings
matt

[Tantratron]

last firmware for C serie.  No i didn't know. 5.2 is newest, what i found.
Newest firmware for D serie is 7.4 and 6.6.  Important notice:  6.6 and 7.4 not interchangable, to difference acquisition board.

tekfwtool is for me useless, this a fact.  I stop to trying with tekfwtool.c. No mood anymore.  I could try it later.

Now , i am going own way with tektool.c.     I am a friends of KISS-principle.
I don't see scrolled display as a problem, a minor code modification solves problem :-)

printf( \r) instead printf( \n)

No worry, I do C programming and other language for decades but my real point is to focus on 2020 best tekXtool suite.

It is not clear to me the storyline or root reason why there was tektool then tekfwtool then getcaldata so it is my hope to understand the logic of all creator of this software. Unless I'm wrong the tekfwtool is the most recent and universal except it can do getcaldata.

Anyway my point is the focus on one single application which can be compiled wether Windows, Linux or C and offers memory management of the NVRAMs, the FlashFile and the EEPROM.

Albert

[Tantratron]

last firmware for C serie.  No i didn't know. 5.2 is newest, what i found.

I look with HEX editor then compare 5.0e then 5.0.1e and finally 5.2e to see what are different TDS models it can run, see attached screenshot

[Tantratron]

last firmware for C serie.  No i didn't know. 5.2 is newest, what i found.

I look back in my computer for previous eBay follow prior purchasing my TDS540C, there seems to exist firmware 5.3e for TDS540C but we would need a donator of the flashfile firmware dumping

[madao]

Good to know.  5.3 is newste Version.
I have asked yesterday my friend about their  TDS754C.  Sad, old fw  5.0e.

Indeed, i am successful with unified tektool.c with autoselect of flash type. (but not fast, 800 seconds for program,(without page-load is not fast)) and  i have  included firmware-verify-check.  ( just type as " tektool -v  v52.bin -b 0x1000000 -l 0x400000") It make copy of firmware from scope and compare it with  data (in this case v52.bin) .




Next step: check  unified tektool.c on  scope with  28F010, 28F020, 28F008SA, then i have reached goal. Then i put it at community.


Side notice: faster program needed  page-load&flash or small firmware (which it is downloading to unit and run as  receiverof data for flashing)  Reason:  GPIB communication with bootloader has much latence. You lost time of nearly 1ms, and ordinary byte-byte program  = 4 byte and you would reached in this case speed ofy 5kb/s, if you transmitting  only 4 byte per block (in my case: 8 byte, frists 4 bytes: commando, seconds 4 bytes: data).

I have foregone page-flash/program at frist, because, i want keep it simple. Maybe, i can added it again, but not for  old flash as 28F010 and 28F020.

[madao]

 Success  with programming  of TDS540

Also success by TLS216 with  28F008SA

I must check with TDS744 (with AMD 28F020). /

It is not fast, but it functions.

[ragge]

Success  with programming  of TDS540
(Attachment Link)
Also success by TLS216 with  28F008SA

I must check with TDS744 (with AMD 28F020). /

It is not fast, but it functions.

Hi Madao,

Very good - and nice with the new "verify" option!

Is it about 10 minutes programming time on all different flash types? That is no big deal I think, one could live with that, to, as you say, keep it simple.

When you have figured out what needs to be done it should be no big deal getting it into tekfwtool too to speed it up, but I have nothing to test it on. And again, I am not sure it is worth it for saving just a few minutes.

Best regards,

Ragnar

[madao]

Hello ragnar

I have  flasher for TDS540, which it runs only with NI PCII/IIA GPIB card and MS-DOS.  It needs less than two minute for programming.

A big problem ist  1ms latence after transfer of telegram to unit.  Result: only a tousand  telegram with 8 byte(4 byte cmd, 4 byte data)  per seconds is possible.
TDS540 flasher works same as   tekfwtool: It uploads  68k file to  memory and it start as  receiver and control flashing of data (timing).


You can  streching telegram up to  512 byte, it would faster.  It works (read /write) good by memory without speed limit and not flash programming. Flash needs more time  (up to 10µs) for writing of data.

Screenshot shows  68k code for flash programming (file is called "burn.mon") It came from old TDS540 flasher. Pleas don't ask for sharing of this tools.  I have promised.


verify function, i say, it is a good aids for check of firmware.

btw.  my nick is madao, not madam ;-)  (madao is a nick of one people from anime "gintama", madam is a old german word for "women" )

btw², it is possible, that  unified tektool works on old TDS400 series. I have  read their flash, same base address 0x100 0000, flash verify works.    It is good sign, despite massiv different structure of TDS400 (it use 68020, but hardware is extreme other)
I have here  a TDS430A corpse with life sign. It doesn't matter, if it died.

[ragge]

Hi Madao,

Thanks for your reply.

Sorry for misspelling your nickname - it was my autocorrect interfering, and I missed that it happened. It even happened again the first time I tried to correct it.

Ok, so a 540 it could be flashed in two minutes, that is good to know.
I have not clocked tekfwtool on a TDS 5/6/7 68040 CPU board with 28F160S5, but I would say it is about the same.

All right - it would be nice if it worked on the TDS400 series too!

Best regards,

Ragnar

[madao]

tekfwtool.exe  need excat 200 seconds for programming of 28F160S5.

Actually: Ich check my unified tektool on TDS430A corpse (TDS420 CPU with AMD 28F010) It is slower than TDS540. (~12-14 minutes)
_________________________________________________________________________________________________________
EDIT:  I have big difficult for programming firmware into TDS420 CPU. Cause: AMD 28F010 has big variations in quality.
One "good" needs only  70 erase pulse, other "notsogood" need 172 erase pulse.  If you did 172 erase pulse at  "good" 28F010, you would get difficult to writing on "good" flash after "overerasing".   I must  replay flash program (5x try -> successful).

What is happend with overerasing? Here my statement:
Old TDS instrument has 12 piece  flash. Four 28F010 is wired as 32bit parallel Flash. If one good and notsogood 28F010 in this group.  My code didn't seperate four flash in one group. This is  a salate ! I'll modified my code to seperating flash for erase.

Why haven't  28F008SA, 28F016SA, 28F160S5 this problem?  It is a intelligent flash and control erase-process . 28F010 and 28F020 is  dumb flash and need external erase control (28F010 & 28F020 has only  timer (10ms) for prevet of overerasing))


Now, i am realizied: Intel 28F010 is very good  product. (needs only  17-18 erase pulse, no big variations)

BTW: tries-counter is "counter down" (at frist is 50 as start-value, now  200)

[ragge]

Interesting.

I have heard that some flashes should be written with all zeroes before erasing, but I have no idea is 28F010 one of those.

[madao]

Yes, zero filling is recommend to old flash as 28F010 and 28F020.
I have included this feartures, but not in erase-function( tektool -z -b 0x1000000 -l 0x10). And  TDS540 flasher didn't use zero-filling (because, i have measure time of erase, tooo short for zerofilling)

And a little news: individual erase on each flash is now  implement. Result: Flashing of  AMD 28F010 is much better, with success.
Modifcation of code is  minor: I use mask for erase commando. Not more :-) But yet not 100% relaible, i must modified code for improving relaiblity.

[DC1MC]

Sorry to resurrect this necro thread  , but I'm preparing to open my TDS740A for a HW repair and I'm also considering a FW update, currently it has ver. 4.1.

Does anybody have a newer, better version and alternatively, is anybody interested in a ROM dump for 4.1 ?

Cheers,
DC1MC

[Tantratron]

Hello all and Happy New Year 2023,

Since end of 2019 I've venturing myself to use TDSxxxC/D in my own lab then buy some more and/or repair some other TDSxxx/C/D units.

The tekfwtool suite was really good (firmware, NVRAMs) and very fast. My return of experience involves now total of 8 units, everything went fine to upgrade, to un-brick but early this year I've found a serious problem with tekfwtool, maybe some of you suffered the same issue.

If for some reason your CPU board uses flash file memories TE28F160S5 model, after erasing then programming the firmware (i.e. upgrade from 6.3.e. to 6.6.e) then the oscilloscope will brick: happened to me on my TDS754D and my TDS784D erlier this year. However the tekfwtool software will do its job very well if the flash files memories E28F016SA, I have two spare CPU board with these flash and no problem.

After a few days of despair, the only solution was to modify the very slow tektool software to save one of my CPU boards but ideally if tekfwtool could cover both flash files memoriy models, this would be the best (tektool is ultra slow whatever you do, tekfwtool due to its 68K cookie installed in the TDSxxx/C/D is very fast).

The version of tekfwtool I've been using for more than 2 years come from this github repo https://github.com/ragges/tektools where unless I'm wrong, the original come from https://github.com/fenugrec/tekfwtool and here https://github.com/svenschnelle/tekfwtool plus getcaldata as well as the floppy method (NVRAM and EEPROM).

As a safety, I recommend those of you using tekfwtool to first check what flash file memory model is installed on your CPU board or be prepared for serios brick, not fatal but you'll loose huge time.

I did fork while ago the repo from ragges to eventually make some modification here https://github.com/tantratron/tektools where I've been always using National Instruments GPIB-USB and Macintosh computer.

Thanks again ,Albert

[fenugrec]

The version of tekfwtool I've been using for more than 2 years come from this github repo https://github.com/ragges/tektools where unless I'm wrong, the original come from https://github.com/fenugrec/tekfwtool and here https://github.com/svenschnelle/tekfwtool

Note : I am not the author of tekfwtool but simply forked dxl's repo. At some point he deleted his repo, and a few years layer re-forked from mine (???). I will add a note to my repo stating it should be considered a read-only backup fork - initially I made it to hold some patches for  DOS support and minor fixes (to run with old ISA GPIB cards).

I think ragges' tektool != tekfwtool, but I'm not familiar with his project. It doesn't look like he forked my repo ? None of my commits are in there.

[Tantratron]

[Note : I am not the author of tekfwtool but simply forked dxl's repo. At some point he deleted his repo, and a few years layer re-forked from mine (). I will add a note to my repo stating it should be considered a read-only backup fork - initially I made it to hold some patches for  DOS support and minor fixes (to run with old ISA GPIB cards).

I think ragges' tektool != tekfwtool, but I'm not familiar with his project. It doesn't look like he forked my repo ? None of my commits are in there.

Strange situation of github owners forking and re-forking or posting source code not fully compiled or checked.

As for ragges github tektoolS repo https://github.com/ragges/tektools his idea was to try gather all the different versions of tektool, tekfwtool, getcaldata and floppy disk NVRAM utilities into one repo. It was necessary and required huge time from him then I was one person back in 2020 to test tekfwtool and getcaldata with my GPIB-USB interface under MacOS.

There have been many different versions, many places storing these tools, never unified or checked but you will see most of his repo comes from your repo except he modified the headers, the compiler options to make them work on Windows NT, Linux and MacOS.

However the problem which I've discovered earlier this year, unfortunately the tekfwtool only works for 28F016SA flashfile and in fact, he tektool only works on 28F016SA as well. I've forked the complete repo then spent some time last week-end to understand the bug or missing part. The problem seems to be in the buffer control versus the page control of each flashfile model which are not the same programming. Worse each unit does not attempt to check the unique flash vendor ID then it applies incorrect programming so result will be bricking the TDSxxxD if its processor boards uses 28F160S5 chips.