Tekfwtool for TDS540C firmware upgrade

[ragge]

this c-sourcefile and all file (inlc. target.bin) came from stackframe.org and i have  compiled tekfwtool  (it is called  tekfwtool0.exe)
 tekfwtool.exe is orginal and is in same folder as tekfwtool0.exe. Orginal runs.

So erasing works with the tekfwtool.exe from stackframe.org, but not with the one you have compiled?
That would be strange, since it is the 68k code in target.bin that does the work, and that is the same.
What error message did you get?
Does it really load the target.bin into the scope?
Had you changed directory "cd" to where the fileas are (otherwise it will not find the target.bin file)?

[madao]

Yes,  tekfwtool.exe from stackframe did their jobs good in same folder with failed tekfwtool0.exe (from me compiled).
CPU board uses 28F160S5.

Error message: Firmware ping failed 00 42 00 00 ( i must checked again, it is only a reminder at this error)
I have compiled now again and  i haven't seeing  warning:   -defaultlib:uuid.lib ' unrecognized| ||Warning: .drectve-  Maybe, it is a problem.

[Tantratron]

Yes,  tekfwtool.exe from stackframe did their jobs good in same folder with failed tekfwtool0.exe (from me compiled).
CPU board uses 28F160S5.

Error message: Firmware ping failed 00 42 00 00 ( i must checked again, it is only a reminder at this error)
I have compiled now again and  i haven't seeing  warning:   -defaultlib:uuid.lib ' unrecognized| ||Warning: .drectve-  Maybe, it is a problem.

Once the EXE application generated after your compile, where do you run the tekfwtool0.EXE

From floppy disk drive) or from your PC computer connected to a GPIB-USB interface to the TDS oscilloscope ?

Albert

[madao]

One opposite-question: Where did you run  tekfwtool? On your MAC ;-)

I give  tekfwtool0.exe up, i press "delete".

Good news.
compiled of tektool.c from ragge's github is sucessful. Thanks for their support over private message.
I have checked their identify-function.
It is a bit buggy.  It sending "PASSWORD PITBULL" over GPIB, it is not neccesary for communication with TDS into bootloader-Mode.
I have removed it.


Bootloader-Mode:  Switch calibration protection (S1002) to *unprotect* and power it , unit start into bootloader-mode.


Remember my qoute.  This byte-pattern is important for identify of flash.   Base-address of flash is 0x100 0000

Code: [Select]

write  <data0x90><addr 0x0000>   // flash identify command
read <addr 0x0000>               // read manufactur identify
read <addr 0x0001>               // read  device identify 
write <data 0xFF><addr 0x0000>   // reset command 

It looks good,  28F160S5 identify (tektool is for 28F016SA)

little bug: after identify of flash, you can't  read  flash corret, because, flash (not all type) stays in command-mode. I have changed code  in yellow circle.  (command at finishs should be 0xFF, not 0x90, it set flash to normal read mode)
A side-notice: tekfwtool haven't this function, despite notice in their help.

I haven't checked their erase commando on my TDS754C.  But it looks good on NI-IO-trace (a tools of NI, listen GPIB Bus)
Correct byte-pattern of full erase command for  28F016SA, which it is ingored by 28F160S5 .



EDIT:  my compiled tektool runs good. Now has my TDS754C  firmware Version 5.2e. Now i can trust this stuff and i can modify tektool for other flash.

[Tantratron]

One opposite-question: Where did you run  tekfwtool? On your MAC ;-)

Yes I did compile then run the C files of tekfwtool on my MAC... native MacBook Air run where it works with National Instruments GPIB-USB-HS interface and both my TDS540C. For the moment I've only dumped or copied the content of both NVRAM and the firmware, I did write the NVRAM but still waiting for flashing firmware and saving-writing the EEPROM.

Again we should thank so much ragge who did provide the stepping stone on his github repositary https://www.eevblog.com/forum/repair/gpib-usb-control-between-macbook-air-(macintosh)-and-tds540c/msg2856510/#msg2856510

Good news.
compiled of tektool.c from ragge's github is sucessful. Thanks for their support over private message.

It looks good,  28F160S5 identify (tektool is for 28F016SA)

little bug: after identify of flash, you can't  read  flash corret, because, flash (not all type) is yet in command-mode. I have changed code  in yellow circle.  (command should be 0xFF, not 0x90)
A side-notice: tekfwtool haven't this function, despite notice in their help.

I haven't checked their erase commando on my TDS754C.  But it looks good on NI-IO-trace (a tools of NI, listen GPIB Bus)
Correct byte-pattern of full erase command for  28F016SA, which it is ingored by 28F160S5 .

EDIT:  my compiled tektool runs good. Now has my TDS754C  firmware Version 5.2e. Now i can trust this stuff and i can modify tektool for other flash.

Let's hope we can converge as a web-team effort for a single unified tekfwtool or tekXtool C files to cover all dumping, writing and flashing situation...

Albert

[madao]

Let's hope we can converge as a web-team effort for a single unified tekfwtool or tekXtool C files to cover all dumping, writing and flashing situation...

Albert

Yes, it is  my goal, one tools for more flash type.  But i'll using my programming stile.

One opposite-question: Where did you run  tekfwtool? On your MAC ;-)

Yes I did compile then run the C files of tekfwtool on my MAC... native MacBook Air run where it works with National Instruments GPIB-USB-HS interface and both my TDS540C. For the moment I've only dumped or copied the content of both NVRAM and the firmware, I did write the NVRAM but still waiting for flashing firmware and saving-writing the EEPROM.

Did it  at last, if you have fallback.  I am your fallback, if  flashing of firmware is failed. But shipping cost and time ...

I did with  NI PCI-GPIB Card and ni-488.2-Driver (include NI-VISA)   Tektool/tekfwtool can be compiled with ni488.h & gpib-32.obj  or other h-file & object-file with same library-function (ibdev, ibsta, ibrd, ibwr).   I got  since few day ago  old  NI GPIB-USB-B adapter. It make no difference, if i set this USB-Adapter to GPIB0.   I'll use it for mobile application.
I'll trying with old IBM Thinkpad with Linux mint. But  my patient is empty ;-) (let me again tell: I hate computer, but i think often good about linux. (no ubuntu , just a amazon-dirt)

Windows gcc compilier is  common "MinGW"

[Tantratron]

EDIT:  my compiled tektool runs good. Now has my TDS754C  firmware Version 5.2e. Now i can trust this stuff and i can modify tektool for other flash.

Hello Matt,

Do you confirm having compiled the tektool.c file from ragge github repository https://github.com/ragges/tektools/tree/master/tektool and could remind precisely what code you have changed " the 0x90 versus 0xFF saga" so it erases properly the 28F160S5 flashfile chip

Do you confirm then to have used the tekfwtoolCc file from ragge https://github.com/ragges/tektools/tree/master/tekfwtool to program the 28F160S5

What do you recommend for my own compiling with MacOS since both my TDS540C has another 28F016SA flashfile chip ?

Hello Ragnar,

I've created a github account for myself https://github.com/tantratron where do you prefer that I fork or modify your own repository to include the MacOS files or shall I rather clone then continue on my own repository ?

Albert

[madao]

EDIT:  my compiled tektool runs good. Now has my TDS754C  firmware Version 5.2e. Now i can trust this stuff and i can modify tektool for other flash.

Hello Matt,

Do you confirm having compiled the tektool.c file from ragge github repository https://github.com/ragges/tektools/tree/master/tektool and could remind precisely what code you have changed " the 0x90 versus 0xFF saga" so it erases properly the 28F160S5 flashfile chip

Yes, it is downloaded from ragge's github.
No,  i haven't modified this tektool.c  about flash support.
I have removed  function with password pitbull and changed  0x90 to 0xFF in identify-function.

But  you can use it as is.

Notice: I have checked it with  CPU board with  28F160S5.  Why ?  This CPU board is spare part, it doesn't matter, if it is bricked.
After checking with GPIB-Listen tools  (NI IO-trace), it is confirmed sending correct byte pattern to erase. Then i have trying with my TDS754C. With success.

But: I wan't keep secret, i have  replaced all  "usleep(xx)" by  "udelay(xx)" with subroutine. Reason: minGW didn't know this "usleep" (a function with  µs-delays) and comment it out. Compiler ask me: Did you mean  '_sleep'  It runs too fast.   Now is OK

Did you confirm your compiler know "usleep(xx)"-subroutine ?

Do you confirm then to have used the tekfwtoolCc file from ragge https://github.com/ragges/tektools/tree/master/tekfwtool to program the 28F160S5

What do you recommend for my own compiling with MacOS since both my TDS540C has another 28F016SA flashfile chip ?

tektool.c from ragge's github, not  tekfwtool.c

[Tantratron]

But: I wan't keep secret, i have  replaced all  "usleep(xx)" by  "udelay(xx)" with subroutine. Reason: minGW didn't know this "usleep" (a function with  µs-delays) and comment it out. Compiler ask me: Did you mean  '_sleep'  It runs too fast.   Now is OK

Did you confirm your compiler know "usleep(xx)"-subroutine ?

Last week and until now, I've only compiled and run native MacOS the tekfwtool modified by Ragge here https://github.com/ragges/tektools/tree/master/tekfwtool. In the 3 files (one C file and tow H files), there is NO line using "usleep(xx)"-subroutine hence can't answer your question.

If you like, I can later this week compile and run the tektool found on Ragge github repository https://github.com/ragges/tektools/tree/master/tektool to see how the Macintosh compiler which is basically a UNIX personalized by Apple do fail or not. However Ragnar informed me by private mail that he will update his github to include many changes and updates so I prefer to wait his GO signal.

I suspect we might have soon early 2020 a unified tekXtool able to read, write, erase where it is highly recommended to have C files and H files to be totally compatible with DOS, Windows, Linux and Mac OS respective compilers. Only via universal C coding confirmed on different POSIX platform we can safely progress on TDSxxx memory management to avoid future bricking.

[Galen]

I'm glad to see these programming talking triggered, and I may try to learn some C language. Now I only can use Assembly of Microchip. 

[Galen]

Report my new test. I got another TDS540C yesterday.  And found the tektool_0 can do the flash (Intel E28F016SA) erase, and firmware write-in.  I didn't try NVRAM reading/writing by tektool_0, I think should be ok.

[Tantratron]

Report my new test. I got another TDS540C yesterday.  And found the tektool_0 can do the flash (Intel E28F016SA) erase, and firmware write-in.  I didn't try NVRAM reading/writing by tektool_0, I think should be ok.

Does anybody has the complete C files and H files of tektool_0 so it could be generalized t Linux and MacOS ?

Thanks, Albert

[Galen]

Report my new test. I got another TDS540C yesterday.  And found the tektool_0 can do the flash (Intel E28F016SA) erase, and firmware write-in.  I didn't try NVRAM reading/writing by tektool_0, I think should be ok.

Does anybody has the complete C files and H files of tektool_0 so it could be generalized t Linux and MacOS ?

Thanks, Albert

Not in the zip.  let's see if anyone have it.

[Tantratron]

Hello Matt,

Could explain why the proper way to erase the flashfile memories involves this LENGTH

Code: [Select]

tekfwtool -e -b 0x01000000 -l 0x10
I understand the start base address to be 0x01000000 but what is the purpose of the " l- 0x10 " arguments when calling tekfwtool or I assume calling the other tektoolx ?

Albert

[ragge]

Report my new test. I got another TDS540C yesterday.  And found the tektool_0 can do the flash (Intel E28F016SA) erase, and firmware write-in.  I didn't try NVRAM reading/writing by tektool_0, I think should be ok.

Does anybody has the complete C files and H files of tektool_0 so it could be generalized t Linux and MacOS ?

Thanks, Albert

We don't know exactly what version of tektool.c that tektool_0 was built from, but it is likely very similar to the one in my repository.

It would be very helpful if someone with a scope with Intel 28F016SA could try the tektool in my repository and check that identification, erasing and programming of flashes work. It should be pretty harmless, as several of you has already managed to reflash with other tools, but I will of course not even recommend it to anyone that does not feel totally comfortable doing it.

(I have now added in my repository that when the programs are built, they will also get what version in the git repo they are built from, and when it was built. This only works if it is built on a machine with working git though.)

Regards,
Ragnar

[ragge]

Hello Matt,

Could explain why the proper way to erase the flashfile memories involves this LENGTH

Code: [Select]

tekfwtool -e -b 0x01000000 -l 0x10
I understand the start base address to be 0x01000000 but what is the purpose of the " l- 0x10 " arguments when calling tekfwtool or I assume calling the other tektoolx ?

Albert

When erasing the flash, the length is not used, only the base is.
Still the argument parser demands that you give a value for both. We should fix that.

Ragnar

[Tantratron]

We don't know exactly what version of tektool.c that tektool_0 was built from, but it is likely very similar to the one in my repository.

It would be very helpful if someone with a scope with Intel 28F016SA could try the tektool in my repository and check that identification, erasing and programming of flashes work. It should be pretty harmless, as several of you has already managed to reflash with other tools, but I will of course not even recommend it to anyone that does not feel totally comfortable doing it.

(I have now added in my repository that when the programs are built, they will also get what version in the git repo they are built from, and when it was built. This only works if it is built on a machine with working git though.)

Regards,
Ragnar

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

[ragge]

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

[Tantratron]

Hello Matt,

Could explain why the proper way to erase the flashfile memories involves this LENGTH

Code: [Select]

tekfwtool -e -b 0x01000000 -l 0x10
I understand the start base address to be 0x01000000 but what is the purpose of the " l- 0x10 " arguments when calling tekfwtool or I assume calling the other tektoolx ?

Albert

When erasing the flash, the length is not used, only the base is.
Still the argument parser demands that you give a value for both. We should fix that.

Ragnar

Ok but how does the tekXtool knows how many bytes it should erase because the memory map starting at 0x01000000 is fixed. The risk is to erase other zoning not used by the firmware, maybe this attached extract document valid only for B series shows the road map.

By the way, no idea on how to find the EEPROM address, that is another topic than the flashfile chip.

[ragge]

Hello Matt,

Could explain why the proper way to erase the flashfile memories involves this LENGTH

Code: [Select]

tekfwtool -e -b 0x01000000 -l 0x10
I understand the start base address to be 0x01000000 but what is the purpose of the " l- 0x10 " arguments when calling tekfwtool or I assume calling the other tektoolx ?

Albert

When erasing the flash, the length is not used, only the base is.
Still the argument parser demands that you give a value for both. We should fix that.

Ragnar

Ok but how does the tekXtool knows how many bytes it should erase because the memory map starting at 0x01000000 is fixed. The risk is to erase other zoning not used by the firmware, maybe this attached extract document valid only for B series shows the road map.

By the way, no idea on how to find the EEPROM address, that is another topic than the flashfile chip.

For the 28F016SA and 28F160S5, it just gives the flash chips commands to erase all blocks, so it doesn't need to know how large they are. (For other models of flashes it could maybe be different though.)

You can not read the EEPROM with tektool or tekfwtool, at least not yet, use the program "getcaldata" for that for now.

If you can, I also recommend doing it the floppy way, and compare the results. Note that the results do differ a little for the NVRAM:s though, I have some information on that in the README.md in my repository here: https://github.com/ragges/tektools.

Regards,
Ragnar

[Tantratron]

You can not read the EEPROM with tektool or tekfwtool, at least not yet, use the program "getcaldata" for that for now.

If you can, I also recommend doing it the floppy way, and compare the results. Note that the results do differ a little for the NVRAM:s though, I have some information on that in the README.md in my repository here: https://github.com/ragges/tektools.

I hesitate to use the floppy getcal EXE or the getcaldata C file then compile in my Macintosh because inside comments https://github.com/ragges/tektools/blob/master/getcaldata/getcaldata.c mention to be valid only for TDS A serie and B serie. Maybe the base address is the same for C series and D series but I'd prefer have access first to the memory map of the scope to make sure I'll really dump at the right place the EEPROM.

Of course maybe I'm to extreme, cautious or perfectionnist 

[ragge]

You can not read the EEPROM with tektool or tekfwtool, at least not yet, use the program "getcaldata" for that for now.

If you can, I also recommend doing it the floppy way, and compare the results. Note that the results do differ a little for the NVRAM:s though, I have some information on that in the README.md in my repository here: https://github.com/ragges/tektools.

I hesitate to use the floppy getcal EXE or the getcaldata C file then compile in my Macintosh because inside comments https://github.com/ragges/tektools/blob/master/getcaldata/getcaldata.c mention to be valid only for TDS A serie and B serie. Maybe the base address is the same for C series and D series but I'd prefer have access first to the memory map of the scope to make sure I'll really dump at the right place the EEPROM.

Of course maybe I'm to extreme, cautious or perfectionnist 

I think you are right to be cautious!

There may very well be differences between models. There is some confusion about the right address of the second NVRAM. That is the main reason for me not publishing that information with my GitHub repository.

I have tried them (getcaldata and tdsNvramFloppyTool) on my TDS 684C:s. They use very different methods of getting the data, from very different addresses that I have no idea how they relate, but they give the same result, which seems good.

I hope and think just reading should not be able to damage anything, but I can of course not guarantee that.

I doubt we will get real memory maps until someone really reverse engineer the hardware of the boards or the firmware and publishes the results, and since that hasn't happened yet I am not very hopeful.

Regards,
Ragnar

[Tantratron]

I think you are right to be cautious!

There may very well be differences between models. There is some confusion about the right address of the second NVRAM. That is the main reason for me not publishing that information with my GitHub repository.

Yeap that is another dark zone or twilight zone we need to be careful, namely the real start address of the 2nd NVRAM, namely the DS1650Y. The real start address of the 2st NVRAM, namely the DS1486 seems to be stable wether B serie, C serie because I did dump then wrote thanks to your github tekfwtool (mac Version) with no bricking plus the behaviour or cloning was correct... see https://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2856798/#msg2856798

However I'd not put my head on the start address of the 1650Y nobody talks really for the C or D serie.

One safe solution I feel is to dump via tekfwtool from 0x04000000 about say 1Mo which means a single file covering the complete memory map of both 1486 and 1650Y for future writing. One option which I've started but not finished due to lack of time is using HX editor (works also on Mac) to look for the Ox00 zoning in order to identify the bordering between 1486 and 1650Y... reverse engineering unless one provides the official tektronix memory map document of different TDSxxx scopes.

[ragge]

One safe solution I feel is to dump via tekfwtool from 0x04000000 about say 1Mo which means a single file covering the complete memory map of both 1486 and 1650Y for future writing.

Yes, I think that should be a safe solution. I saw that recommended somewhere (forgotten where), and it seems to work on my scopes, at least.

Regards,
Ragnar

[madao]

i wouldn't recommend  fixing of   base-address in erase commando, because people must type base adress to confirm 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