Tekfwtool for TDS540C firmware upgrade - Page 1
Forum section: electronics / repair

author: Galen
author_rank: Regular Contributor
timestamp: December 25, 2019, 09:01:18 am
content: Hi All, I'm considering to upgrade my TDS540C firmware from 5.0e to 5.2e, to let the banner can show TDS580C, after I upgrade this 540C to 580C.The most suitable tool is tekfwtool, I think. Even some posts talked a little about tekfwtool, but no dedicated topic about this, I read all them and still not sure about the environmental needed. So I decided to open this thread, dedicating to this tool.What I have/know now:1. A PCI-GPIB card (brand NI), on the way to me.2. A NI GPIB cable, on the way to me.3. An old computer with PCI slot.4. Windows98 SE installation CD, and WinXP installation CD (SP3).5. The firmware of version 5.2e, downloaded.6. tekfwtool.exe, and the source code (download from the link in eevblog: 'source-code and tekfwtool.exe for using (run only with NI-VISA and Windows',https://stackframe.org/tekfwtool/). It's said this tekfwtool only works in Win98 DOS window mode.My question:1. Still need the NI-VISA to drive the GPIB card, right?2. Based on information on NI website, if I use Win98SE, I need the NI-VISA Ver3.0.1 or lower, but can't find the download. The lowest version is Ver5.4, I downloaded it from NI site, but it supports WinXP SP3 and above (Win7, Win8, etc.)So question now is, to use this tekfwtool, I need to find NI-VISA 3.0.1 or lower. But searched the net, can't find a link. If I use WinXP, then this tekfwtool still works?I saw a post said the tekfwtool source code need to be compiled using some tool, but I have no idea how to do it, as I'm not a computer programmer.Any help on this is very appreciated.Best Regards,Galen

author: madao
author_rank: Frequent Contributor
timestamp: December 25, 2019, 01:25:22 pm
content: I use tekfwtool with NI PCI-GPIB card and Win 7 x64.I can updating firmware of my TDS754D (now is it TDS784D) from 7.11 to 7.4IEEE488.2 17.1 (include NI VISA)Single trouble: i cannot updating my TDS754C firmware (similar as your TDS540C w/o color)Unit must be running into boot mode. ( cal switch to unprotect and power it)Quote

author: Galen
author_rank: Regular Contributor
timestamp: December 25, 2019, 03:23:13 pm
content: Thanks a lot madao!As I know, the C serials, firmware version 5.2e should support. Because can find many C models in the firmware.could you attach the tekfwtool which you used to here? I downloaded one but don't know it works or not.Very appreciated.Galen

author: Galen
author_rank: Regular Contributor
timestamp: December 25, 2019, 03:42:51 pm
content: Hi madao, I mean Tds784c firmware 5.2e. Just checked the Fw, tds784c and tds794 model number are inside. maybe you can try it.Or, it's because the flash ic is not supported by the tekfwtool? Therotically, if the flash ic model is the same, this tekfwtool should work.Galen

author: Galen
author_rank: Regular Contributor
timestamp: December 25, 2019, 04:21:11 pm
content: my tds540c flash ic is E28F016SA 16-MBIT (1 MBIT X 16, 2 MBIT X 8)FlashFile MEMORY.so this tekfwtool should works?

author: madao
author_rank: Frequent Contributor
timestamp: December 25, 2019, 06:45:58 pm
content: TDS700C firmware fit also in TDS500C .I have upgrading my TDS754D with Firmware of TDS784D (V7.4), no trouble.Other case with TDS714L is upgraded with TDS794D (V6.6) Firmware.Yes, 28F016SA (and 28F160S5) is support by tekfwtool. But i have problem to upgrading my TDS754C. (error by earse of flash)Not more.. sadly, i am needed firmware-upate on instrument with 28F020 and 28F008.Important ! downloading all file from page, include target.bin. NEVER modified and replacing him.Pleas don't ask for make of c-sourcefile for executable file. I am sorry, i haven't know about it.Again ! It is your risk, what you doing it. Pleas don't hit me ! ;-)

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 27, 2019, 10:21:27 am
content: Hello Galen,I'm bit like you trying to connect the dots between different threads, infos dealing on how to save or upgrade firmware as well as on how to save or load the NVRAM via software.Wether tektool or tekfwtool, there is a need to first make sure GPIB link works correctly to read-write on the different memory maps. It seems both softwares are written in C then it is just matter to compile then link wether Windows, Mac, Linux.There are 2 interesting thread you might already know but still not clear to mehttps://forum.tek.com/viewtopic.php?f=568&t=139999&hilit=TDS784/https://forum.tek.com/viewtopic.php?f=568&t=138168&hilit=TDS784/It would be interesting to have the complete memory map of TDS serie C and D which are using 68040 whereas TDS serie no-suffix, A or B uses 68020. Attached the one of TDS520B but we would need similar info for TDS 540C to really make sure not writing or corrupting the internal memories. For example in this casehttps://www.eevblog.com/forum/repair/gpib-usb-control-between-macbook-air-(macintosh)-and-tds540c/msg2840286/#msg2840286it would be nice to have an answer why address Ox50009 does not correspond to the 0x4000000 mentioned as NVRAM start in the B-version memory map. Unless the options are stored somewhere else than in the NVRAMs...One thing which I do not understand, in my case I'm using Macintosh with complete free NI (National Instruments) software to interface with GPIB, for instance VISA. I do have two TDS 540C where attached pictures of the GPIB numbering wether NVRAM disabled to write and NVRAM enable to write. I did choose GPIB address 2 and it shows up correct when booting the TDS in normal mode but it shows for some reason 0x29 when NVRAM is write-enable... why no idea but notice this very same address is used in the tektool.c software and probably in the tekfwtool.cAnother route I'm exploring is to use Python where there seems to be VisaPy compatible with GPIB, NI-488.Lastly I did manage to also send GPIB commands via a GPIB Terminal from my macintosh where all this command stuff should be universal wether Windows, Mac OS or Linux... seehttps://www.eevblog.com/forum/repair/gpib-usb-control-between-macbook-air-(macintosh)-and-tds540c/Albert

author: Galen
author_rank: Regular Contributor
timestamp: December 28, 2019, 05:04:49 pm
content: Hi Albert,Thank you very much for sharing so many information on this. My NI PCI-GPIB card and cable just arrived today. So still no time to try it on my computer.My computer has PCI slot, it run Win7 now. But I had run DOS on it before, using floppy disks, it has a floppy drive. But no DOS drive for this GPIB card. So I will try Win7 first to test the card and communication with the TDS540C. Will update here the progress.Thanks againGalen

author: Galen
author_rank: Regular Contributor
timestamp: December 28, 2019, 05:25:17 pm
content: Hi Albert, if you only want to activate the option, then the floppy tool can be used, pls refer my posthttps://www.eevblog.com/forum/testgear/activate-options-for-tds5xx-6xx-7xx-cd-using-floppy/msg2237949/#msg2237949This tool is developed by flyte, I have used it successfully add options for my TDS540C. you can try it.Galen

author: Galen
author_rank: Regular Contributor
timestamp: December 28, 2019, 05:35:04 pm
content: The floppy tool post by flyte, a lot discussion inside.https://www.eevblog.com/forum/testgear/tektronix-tds500600700-nvram-floppy-dump-tool/msg2244054/#msg2244054

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 28, 2019, 05:54:12 pm
content: Quote from: Galen on December 28, 2019, 05:25:17 pmHi Galen, to activate any option is easily done by software and NI-GPIB-USB-HS interface wether you're using Windows, Mac or Linux. In my case, I've done it this week with my MacBook Air as you can read this posthttps://www.eevblog.com/forum/repair/gpib-usb-control-between-macbook-air-(macintosh)-and-tds540c/msg2839268/#msg2839268At some point if we can manage everything via GPIB and software, this will be much quicker, safer and cheaper. However on the topic to copy NVRAM and the firmware, I'm still on my learning curve so not sure how to do it via GPIB with my Macintosh.My point anyway, once USB-GPIB link exists then it solves already the topic to enable options and frees from more complex old equipment like Floppy disk and non-official tektronix tool kit.I do need to solve the NVRAM and firmware update so your thread helps as a trigger.By the way, I do have a TDS540C like yourself with firmware V5.0.E so maybe you could share the most recent firmware version if it is authentically dumped from a working TDS540CThanks, Albert

author: Galen
author_rank: Regular Contributor
timestamp: December 28, 2019, 05:56:46 pm
content: Hi Albert, you said'I did choose GPIB address 2 and it shows up correct when booting the TDS in normal mode but it shows for some reason 0x29 when NVRAM is write-enable...', I think it's the boot loader fixed this GPIB address at 0x29, to 'listen' any command wheNVRAM switch is put in unprotected. That's the reason that tekfwtool use GPIB address 0x29.Galen

author: geostep
author_rank: Regular Contributor
timestamp: December 30, 2019, 10:55:39 pm
content: Hi Galen,I have a Tek 540C as well running V5.0e. I'm interested in upgrading it to 5.2 (or better).Could you please share the files. And any notes regarding firmware changes?I did a quick Google search but couldn't find any hits on 540C firmware.Thanks!- George

author: Galen
author_rank: Regular Contributor
timestamp: December 31, 2019, 04:01:42 am
content: Hi George,you can go to KO4BB, then Mnuals, search for TDS784C, you can find the 5.2 firmware.The tools include: tekfwtool, GPIB card, computer of cause, and NI-488, NI-VISA. I have downloaded the original firmware and NVRAM. But still not try to change the firmware now.May I know what triggered the firmware change for you?Regards,Galen

author: Galen
author_rank: Regular Contributor
timestamp: December 31, 2019, 04:26:19 am
content: HI George, I mean updating the firmware is a risky job. May brick your scope. So far, I didn't try that, so no more comments now. May be some body in this forum who success in updating TDS540C, but I didn't find from search.thanksGalen

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 31, 2019, 05:00:52 am
content: Quote from: Galen on December 31, 2019, 04:26:19 amYour thread is bit dangerous because in the first place, you say to have the 5.2e firmware for a TDS540C then it turns out you've found only the 5.2e firmware for TDS784C from this websitehttp://www.ko4bb.com/getsimple/index.php?id=manuals&dir=Tektronix/Tektronix_-_TDS5xx_TDS6xx_TDS7xx_Digital_Phosphore_Oscilloscopes/TDS784C_firmware_v5.2eMaybe the TDS784C firmware would work on TDS540C, no idea but for sure but direct tekfwtool writing to NVRAMs EEPROMS might be fatal if no basic information on the memory map, how the SW checks the HW options...On a side note, this other webpagehttp://www.ko4bb.com/getsimple/index.php?id=enable-tds754d-optionsof KO44B is very useful as a synthesis of how easy we can set options by SW, modern GPIB communication with any type of computer

author: Galen
author_rank: Regular Contributor
timestamp: December 31, 2019, 06:07:21 am
content: Hi Albert, the TDS784C firmware downloaded from KO4BB also works for TDS540C and TDS580C, and many other TDSxxxC. Because I checked that firmware, TDS580C and TDS540C model number are inside, plus many other TDSxxxC listed inside.I have dumped the 5.0 firmware from my scope, the TDS580C is not listed in side. So obviously, it doesn't support TDS580C. That's the reason I got 'TDSxxx' in the banner.Thanks,Galen

author: geostep
author_rank: Regular Contributor
timestamp: December 31, 2019, 11:16:47 pm
content: Hi Galen,Thanks for the insight and cautions. I'm interested in opening up my 540C to a 580C as well. Yes, there are risks including bricking. It would be nice to see if it will display 580C instead of xxx when trying the 16 different 0 ohm jumper combinations. As well as getting the scope to 1 GHz. Not that I don't need a 1 GHz scope, but there is fun and adventure in trying to get there.- George

author: geostep
author_rank: Regular Contributor
timestamp: December 31, 2019, 11:43:05 pm
content: I looked at the version 5.2e binary file that Tantratron referenced from the KO4BB website.In the file "TDS784C_fimware_EPROM_5.2e_flashmem.bin" the following info can be found starting at location 284C34h. I have replaced null (00h) characters with commas for clarity.TDS 784C,TDS 744,TDS 744C,TDS 724C,TDS 540C,TDS 520C,TDS 782C,TDS 754C,TDS 794,TDS 580C,TDS xxx,$VersionString:It does hint that this file *could* be used on all of these models.If anyone reading this knows this to be true/has done this firmware upgrade please speak up and let us know about your experience, good or bad.- George

author: Galen
author_rank: Regular Contributor
timestamp: January 01, 2020, 05:32:30 am
content: The tekfwtool I used can't program the flash properly, in Win7 + PCI-GPIB. After I flash the new firmware in, the TDS540C can't start. then I flash in the original backuped firmware, it still dead.sad......

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 01, 2020, 05:37:36 am
content: Quote from: Galen on January 01, 2020, 05:32:30 amDo you mean and confirm now your TDS540C is bricked or dead ?

author: Galen
author_rank: Regular Contributor
timestamp: January 01, 2020, 05:42:26 am
content: Quote from: Galen on January 01, 2020, 05:32:30 amI read the firmware after flash it in, use hex editor to compare them, there are many data un-match.Because the write-in is too fast?

author: Galen
author_rank: Regular Contributor
timestamp: January 01, 2020, 05:44:46 am
content: Quote from: Tantratron on January 01, 2020, 05:37:36 amit can still communicate with the tekfwtool. Just the write-in has a lot wrong data.so I think it's not the firmware problem, it's the tekfwtool I used not write-in the right data.

author: madao
author_rank: Frequent Contributor
timestamp: January 01, 2020, 05:45:03 am
content: It must be erase at first. Without erase is correct programming of flash impossible.Write of flash is much other than ordinary memory.Saving of him is possible, you need Flasher, which could flash this type, desoldering him.

author: Galen
author_rank: Regular Contributor
timestamp: January 01, 2020, 05:58:10 am
content: Quote from: madao on January 01, 2020, 05:45:03 amI used the erase command -e -b 0x01000000 -l 0x10, isn't right? why the length is so short (0x10)?thanks.

author: madao
author_rank: Frequent Contributor
timestamp: January 01, 2020, 06:06:18 am
content: Yes, "tekfwtool -e -b 0x1000000 -l 0x10 " is correct.short lengt, it is a erase-command for flash, flash begin erase their memory. flash must be empty.

author: Galen
author_rank: Regular Contributor
timestamp: January 01, 2020, 06:08:47 am
content: Quote from: madao on January 01, 2020, 06:06:18 amThanks Matt. try this now.

author: madao
author_rank: Frequent Contributor
timestamp: January 01, 2020, 06:23:01 am
content: and a important notice: command for writing flash is only "-p" , use never "-w". It doesn't work on flash memory.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 01, 2020, 06:24:08 am
content: I'd like to compile the C files of tekfwtool on my Macintosh, for the moment I've found this archivehttps://stackframe.org/tekfwtool/but dates are 2013.Does anybody has the complete C files and H files of more recent date, where can we find the most recent files of tekfwtool ?For the moment, I'm using with success a National Instruments GPIB-USB-HS interface but if I find a HP Agilent 82357B GPIB-USB interface then I'll try to see how it works from my Macintosh... seehttps://www.eevblog.com/forum/repair/gpib-usb-control-between-macbook-air-(macintosh)-and-tds540c/msg2852474/#msg2852474

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 01, 2020, 06:25:30 am
content: Quote from: madao on January 01, 2020, 06:06:18 amHey Matt, what is exactly the ASCII character of " -l"... do you confirm "small L" ?

author: madao
author_rank: Frequent Contributor
timestamp: January 01, 2020, 06:26:17 am
content: yes ! it means lenght.

author: Galen
author_rank: Regular Contributor
timestamp: January 01, 2020, 07:11:56 am
content: THanks Matt.tried -e again, then -p, the write-in data still many errors. Machine can't start.so this tekfwtool didn't do the job as expected.now, better to find a programmer, desolder the flash and program them. or wait for tekfwtool revision.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 01, 2020, 07:23:54 am
content: Quote from: Galen on January 01, 2020, 07:11:56 amIndeed clarification on different builds of tekfwtool would be advisedhttps://www.eevblog.com/forum/repair/gpib-usb-control-between-macbook-air-(macintosh)-and-tds540c/msg2852488/#msg2852488

author: Galen
author_rank: Regular Contributor
timestamp: January 01, 2020, 07:51:01 am
content: Quote from: Tantratron on January 01, 2020, 07:23:54 amYes. I'm thinking maybe I will try to compile an. exe using the tekfwtool. c. But many to learn.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 01, 2020, 07:58:49 am
content: What is the chip name (reference Uxyz) on the TDS540C hosting the flash firmware ?

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 01, 2020, 09:19:56 am
content: One key question would be to know if there are some software correlations or cross-check or cross-integrity between the content of the 4 memories which are savedhttp://www.ko4bb.com/getsimple/index.php?id=manuals&dir=Tektronix/Tektronix_-_TDS5xx_TDS6xx_TDS7xx_Digital_Phosphore_Oscilloscopes/TDS784C_firmware_v5.2eThe website shows 4 zones, 4 chips each with their own software content but is it confirmed one can for example load on chip with new firmware without loading the 3 other chips content.For example, say we update the 1486 only, is it OK to leave previous version of 1650Y ?Same question, say we update the firmware flash memory, is it OK to leave the boot eprom with its previous software version ?On a side note, would it be safer to rather update firmware from TDS754C which has same GHz speed than TDS540C ?How about the safety to update firmware from Color CRT version into Monchrome CRT version ?

author: madao
author_rank: Frequent Contributor
timestamp: January 01, 2020, 10:10:22 am
content: Quote from: Galen on January 01, 2020, 07:11:56 amI can make flash dump from flash in TDS754C , but not now and Firmware is old 5.0e.Here a dump by tekfwtool. It mus be chopped to fit direct in flash (1 &2th byte in frist flash, 3&4th byte in seconds flash, i am not 100% sure) I want help you.What art of error make tekfwtool?erase error ?Quote from: Tantratron on January 01, 2020, 07:58:49 amNo glue, but i can say, it is saved in two E28F016SA

author: Galen
author_rank: Regular Contributor
timestamp: January 01, 2020, 05:09:39 pm
content: Hi Matt, the erase fail, after erase, I read the firmware using -r, still not all 'FF', original data still there.erase takes about 2-3 minutes, show message in below picture.

author: geostep
author_rank: Regular Contributor
timestamp: January 01, 2020, 05:23:15 pm
content: Galen, where did this erase command come from? It would make sense that the erase length should exactly equal the length of the data being written.Also, if you read back the first 10h bytes are they indeed blank?- George

author: madao
author_rank: Frequent Contributor
timestamp: January 01, 2020, 06:38:53 pm
content: Same problem by my TDS754C, and i give up with trying of updating.It is not bricked, if you give up at this point.I tell you, TDS700D use also TDS700C CPU Board.Pleas wait: i ask friend for flasher with support for TSOP56 flash. (i haven't it).It take about one weeks.@geostep, no, this command with 0x10 length is correct, i use it at first with success on my TDS714L (it has wrong firmware, it doesn't matter, if it is dead)https://web.archive.org/web/20131212025232/https://stackframe.org/tektool.shtml(Important: it is for tektool, not tekfwtool, but erase command is same)

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 01, 2020, 06:47:32 pm
content: Quote from: madao on January 01, 2020, 06:38:53 pmWhat happened to your TDS754C, what is the problem or issue after you try to upgrade the firmware and/or NVRAMs content ?

author: madao
author_rank: Frequent Contributor
timestamp: January 01, 2020, 06:51:09 pm
content: Quote from: Tantratron on January 01, 2020, 06:47:32 pmnothing happens. = It runs, as nothing happens.

author: ragge
author_rank: Regular Contributor
timestamp: January 01, 2020, 09:26:07 pm
content: The output from your tekfwtool does not look like any of the versions I have seen, the strings are a little different, what version is that?The '50 50 00 00' is the response from the 68 k code it has downloaded, and the first 50, or rather 'P', indicates that it has identified the flash types and should be good to go. (The second 50 is a checksum (which is as simple/bad as just the sum of the rest of the bytes).)Have you tried with:https://stackframe.org/tekfwtool/https://github.com/fenugrec/tekfwtool?They should say:Code:Downloading firmware to scopePinging firmware50 50 00 00Firmware downloaded(I think - I am just reading the code, I am not up to erasing any flashes right now.)Ragnar

author: Galen
author_rank: Regular Contributor
timestamp: January 02, 2020, 01:09:41 am
content: Quote from: geostep on January 01, 2020, 05:23:15 pmHi George, i read the firmware after the erase, not blank. Data still inside. So the erase s not successful. This will result the wrong write-in, based on the flash chip write-in principle.Galen

author: Galen
author_rank: Regular Contributor
timestamp: January 02, 2020, 01:25:00 am
content: Hi Matt, I will stop here.I read some information about flash write-in, looks like if the the flash chip is not erased to FF for all byte, the followed write-in will be wrong. because the write-in can change 1 to 0, but can not change 0 to 1. The erase process is to set all the bits to 1 (all byte to FF), right?Thanks,Galen

author: Galen
author_rank: Regular Contributor
timestamp: January 02, 2020, 01:58:22 am
content: Quote from: ragge on January 01, 2020, 09:26:07 pmI remember tried the tool from Stackframe. can try again.Do you know who is the author of the tekfwtool?thanksGalen

author: ragge
author_rank: Regular Contributor
timestamp: January 02, 2020, 02:02:15 am
content: Quote from: Galen on January 02, 2020, 01:58:22 amSorry, I don't know who is the original author.Also, there seems to be at least two versions of "tektool", made for different flash ships, I can give you some pointers if the Stackframe tekfwtool does not work.Also, if it doesn't work, can you please take a "tektool" and use "-i" to see if it manages to identify the flash?Ragnar

author: Galen
author_rank: Regular Contributor
timestamp: January 02, 2020, 03:02:43 am
content: As the flash wrong write-in is very possible caused by the tekfwtool erase function not works for the TDSxxxC, if can may a eraser hardware, erase the flash without desolder it, then can use tekfwtool to write-in the firmware. This may works?

author: ragge
author_rank: Regular Contributor
timestamp: January 02, 2020, 03:08:34 am
content: I believe it is much simpler to first try with the other "tekfwtool", and then the different "tektool":s, and if neither of those help, see if there is some other software fix.As I suggested, you can also try if one of the "tektool":s manages to identify the chips, and if not, open it up and read on them. If you know what model they are, it should be able to modify "tekfwtool" or "tektool" to erase them.Also, I find it very likely that you can't erase the flash without desoldering it.Ragnar

author: madao
author_rank: Frequent Contributor
timestamp: January 02, 2020, 04:33:12 am
content: Quote from: Galen on January 02, 2020, 01:25:00 amYes, this is a problem, why erase of flash is important.Quote from: Galen on January 02, 2020, 03:02:43 amC-serie CPU Board is also used in (early)500/700D-Serie. (28F016SA) This should not be a problem. But Result is other than good, bad!@ragge, have you complied tektool for this flash (should works w NI VISA)? For galen and me.tektool.c from wayback support this flash. But, i am dumb to make executable file of him.

author: Galen
author_rank: Regular Contributor
timestamp: January 02, 2020, 05:03:43 am
content: Quote from: ragge on January 02, 2020, 03:08:34 amHi Ragge, I can try other tekfwtool/tektool.but limited to the exe. because I don't know how to compile the c program.if you don't mind, could you help to compile a tektool or tekfwtool which support E28F016SA, and can work in Win7 command window? that will be a great help. Very appreciated.Galen

author: ragge
author_rank: Regular Contributor
timestamp: January 02, 2020, 03:51:31 pm
content: Quote from: Galen on January 02, 2020, 05:03:43 amHi,I can build for Linux x86 or ARM (or you can trivially do it yourself), or for MacOS.If you are using DOS/Windows, and can't build programs, first try the tekfwtool at:https://stackframe.org/tekfwtool/If that doesn't work, there is a "tektool5" that uses other commands to erase that someone has made, probably for a reason.In the zip file here:https://forum.tek.com/download/file.php?id=24983&sid=de2267bdadfd0a11ce92f2d5648d656ethere are:TekTool_0.exetektool_1.exeTektool5.exeSomeone said that "tektool_1.exe" does not work.Try these.If they still do not work - try identifying the flash using the "-i" flag, and put the result here.In any case, it would likely be helpful to all of us to understand exactly what flash chips they have put in your machine, along with the model number of the CPU board.If you could take a picture or the chips and the model number, or just write it down, that would be nice!Regards,Ragnar

author: madao
author_rank: Frequent Contributor
timestamp: January 02, 2020, 05:32:42 pm
content: My TDS754C ingore erase commando from tekfwtool and i give up trying with erase. This is why, my TDS754C is not bricked, i have not a reason for update of firmware. -> "nothing happens", i mean, it is not changed and runs good as is.CPU Board: 679-4172-00 w 28F016SA (a notice, this CPU board is also used in early 700D-Series)Galen wrote me, he has sucess with erase of firmware with tektool_0. He use tekfwtool program of flash. It came back to life :-)Now is clear, tekfwtool has problem with erase of 28F016SA.i guess, tektool_1 works with GPIB_1 card. Most GPIB card run in system as GPIB_0 (my NI PCI-GPIB runs also as GPIB_0)greetingsmatt

author: madao
author_rank: Frequent Contributor
timestamp: January 02, 2020, 05:36:19 pm
content: removed, double post.

author: ragge
author_rank: Regular Contributor
timestamp: January 02, 2020, 10:33:20 pm
content: Quote from: madao on January 02, 2020, 05:32:42 pmWhat tekfwtool are you talking about?So have you tried the different tekfwtools and tektools?Quote from: madao on January 02, 2020, 05:32:42 pmSounds very reasonable, and thanks for the CPU-board-to-flash-mapping-information!Quote from: madao on January 02, 2020, 05:32:42 pmGood! Do we know what CPU board and flash chips is in Galen's scope?Quote from: madao on January 02, 2020, 05:32:42 pmAgain, what tekfwtool do you mean?The tekfwtool:s that I pointed out is supposed to support both 28F016SA and 28F160, but of course things may be broken in it.The "Tektool5" erases flash in a third way. Maybe there are actually three different kinds of flashes in TDS scopes, maybe there are just two.Quote from: madao on January 02, 2020, 05:32:42 pmWhy do you think that? The program has no idea what the device is called.Looking at the source, one difference compared to some other random tektool.c (why are there so many, and all more or less broken???), is that it assumes GPIB address 1 for the instrument.But then, what would 5 in tektool5 mean? Could be flash type "inte_s5", but it does not handle s5 flash in the same way as the tekfwtool I pointed out.(The other random tektool.c assumes GPIB address 0x29, or decimal 41, for the instrument, which is also totally wrong, it should be 29 (decimal)).Ragnar

author: Galen
author_rank: Regular Contributor
timestamp: January 03, 2020, 03:14:31 am
content: Hi Ragge, thanks for the advice to trying other tektool. I tried these tools I have, finally, tektool_0.exe make the erase successfully. Then use the tekfwtool to write-in the firmware, successful.Now, it is clear, the tekfwtool I used can't erase the 28F016SA in Win7 + PCI-GPIB card.My TDS540C live again. Thanks all who provide suggestion during this process.Galen

author: madao
author_rank: Frequent Contributor
timestamp: January 03, 2020, 03:19:07 am
content: tekfwtool came from stackframe.org/tekfwtool , galen got this version from me. This version can't erase 28F016SA, but it do good jobs by 28F160S5. I don't know other tekfwtool.exe.galen's TDS540C CPU Board use also 28F016SA.tektool_0 use GPIB0 , it is only my guess. Galen and i use win7 & NI-VISA (and their GPIB card) and tekfwtool runs with same behavior with 28F016SA erasing.In both C-sourcefile (tektool & tekfwtool) exists "ibdev(0,0x29,)"commando. This commando choose GPIB card and GPIB -Device.But your point with tektool_5 maybe correct. Many broken tektool...possible, it is running with other than NI-VISA and GPIB-card stetting..

author: geostep
author_rank: Regular Contributor
timestamp: January 03, 2020, 03:35:18 am
content: Quote from: Galen on January 03, 2020, 03:14:31 amThat's really good to hear Galen! I was not happy to read that your first attempt went so badly. What firmware is your scope at now, 5.0e or 5.2e?Still interested in upgrading my 540C at some point when I have gathered much more data on how to proceed with relative safety. I'll be using tektool and an old PC with a GPIB card when I do.BTW, I just enabled option 2F on my 540C using Flytes floppy disk commands and a hex editor! Next step will be enabling option 2M.- George

author: madao
author_rank: Frequent Contributor
timestamp: January 03, 2020, 04:10:57 am
content: I have downloading zip-file with tektool from ragge's link.Tektool5's sourcefile exists and i read it (erase and identify)erase commando: 0x20 , 0x20, then wait (10ms), 0xA0. Datasheet of 28F020 tells exkat this step for erase.but identify = 28F160SA. Probably, it is disabled by other author.tektool5.cCode:tatic int flash_erase(uint32_t base){uint32_t buf;int count = 0, ret = -1;while(count < 100){if (flash_command(base, 0x20) == -1)goto out;if (flash_command(base, 0x20) == -1)goto out;usleep(10000);if (flash_command(base, 0xA0) == -1)goto out;usleep(6);if (read_memory(base, (uint8_t *)&buf, sizeof(buf)) == -1)goto out;if ((be32_to_cpu(buf)) == 0xffffffff ){ret = 0;break;}else {count += 1;}}

author: Galen
author_rank: Regular Contributor
timestamp: January 03, 2020, 04:27:19 am
content: Hi geostep, my scope has 5.2e firmware now.

author: ragge
author_rank: Regular Contributor
timestamp: January 03, 2020, 06:27:58 am
content: Quote from: madao on January 03, 2020, 03:19:07 amI would say it can't be, since the output strings do not match, but I now see that the strings in the source code does not match the strings in the .exe file! So whoever put that stuff there, did not put matching source code and compiled code there!So has anyone decompiled that program and checked what itactuallydoes? Does it send your entire hard drive to someone? Install back doors on your machine?This is one of the many reasons why Windows is so deeply unusable - how the programmers and users use it - they just copy random binaries around, no-one knows where it came from, what version it is, what it actually does, or how many extra virus programs that have installed itself in it. In the Unix world, or for almost any normal operation system (anything but windows), one has learnt to keep track of those things since the 1950:s, and today more than ever.Quote from: madao on January 03, 2020, 03:19:07 amOk, good!Quote from: madao on January 03, 2020, 03:19:07 amYou are right - the first argument is the device number, I had forgotten, my bad!I hope you haven't found any more place with "0x29" as GPIB address, since that is 41 decimal, and the largest valid GPIB address is 30. Again, it should be 29 (decimal) if they mean a TDS booted NVRAM Unprotected mode (at least mine, seemingly many others too).Best regards,Ragnar

author: ragge
author_rank: Regular Contributor
timestamp: January 03, 2020, 06:34:48 am
content: Quote from: madao on January 03, 2020, 04:10:57 amGood that you found that match!Well, the source code is there, and there is a binary (or in the DOS world: a "exe"), called tektool5, so I don't think anything is disabled. I haven't checked if the binary does the same thing as the source though.Someone for some reason did this, which I think is interesting. There could be many reasons, but one of them is that someone actually had some flashes that worked differently.Regards,Ragnar

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 03, 2020, 06:36:24 am
content: Quote from: ragge on January 03, 2020, 06:27:58 amI confirm this specific point when connecting my TDS540C, unprotected mode and USB-GPIB-HS communicating with my Macintosh... the valid GPIB address is 29 decimal whereas with protected mode, it will use the GPIB address defined by myself on the TDS540C. For instance I did choose 2 to make it different that the USB-GPIB-HS interface seen from my computer, my interface has GPIB address of 0

author: madao
author_rank: Frequent Contributor
timestamp: January 03, 2020, 02:55:25 pm
content: Quote from: ragge on January 03, 2020, 06:27:58 amI write short: i don't like computer, whatever art of operationsystem. I am glad, if computer do their jobs and don't annoys me.You would not believe me, i use win 7 since 7-8 years and i haven't got one virus. Best virus defender is functional brain.I know dumb guy, he install many (2-4 ) anti virus programm and firewall and got virus on fresh system.Albert know that, i hate computer. But i drive two track with linux (linux mint) and Windows. I avoid often change of system, because i have less patient with computer.Despite this fact, i have a programming skill (special c-source for µC.) and learning actually verilog for FPGA.@ hex-decimal 0x29You're right with hex-value of device address. Now i don't know, why is this count hex-decimal and not decimal.I have reading progamming manual of IEEE488.2 of NI, it tells only 0-30 , nothing one word about hex. Wreid !@ tektool5This tools is very intererssing, because we need flash tools for older instrument with 8bit-flash as 28F010, 28F020, 28F008SABut, i must expose with computerfor compiling of c-source-file.EDIT: i am sucessful with make of executable tekfwtool, Good, now i'll hunting old TDS540 and similar for checking of flash erase & programming. Unfortunately, i have sold my TDS540 since a month ago.

author: ragge
author_rank: Regular Contributor
timestamp: January 04, 2020, 08:14:50 am
content: Quote from: Galen on January 03, 2020, 03:14:31 amHi Galen,I am happy to hear that it helped!All this will probably also help others in the future, which is nice!Ragnar

author: ragge
author_rank: Regular Contributor
timestamp: January 04, 2020, 08:18:35 am
content: Quote from: madao on January 03, 2020, 02:55:25 pmAh - compiling is no big deal! :-)Quote from: madao on January 03, 2020, 02:55:25 pmVery nice! So you can now compile the 68k part too?Regards,Ragnar

author: madao
author_rank: Frequent Contributor
timestamp: January 04, 2020, 08:32:41 am
content: Pleas wait. I must get spare parts from storage. (sucessful repaired TDS700D CPU Board & more acquisition board & TDS540A-corpse)I haven't time today. I'll trying with him tomorrow or monday. But short check with dumping of NVSRAM, it look good. True hurdle is erase & program of flash.AH ! I tell you: "Ping Firmware 50 50 00 00" is happens also by this TDS700D CPU board w 28F160S5 and did good their jobs.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 04, 2020, 08:46:25 am
content: After all this saga and recovery progress, don't you think guys that maybe we should go towards a unified or universal tekXtool able to cover all TDSs hardware and software scenarios. After all it seem clear that tektool.c only deals with NVRAM, the tekfwtool.c covers NVRAM EEPROM and Flash except some IC chips require special erase-writing C commands.What is quite interesting and refreshing, the mixture of test, ideas and track between DOS, Windows, Linux and Mac OS seems to bring cleaning many topics plus now we have proof if GPIB-USB interface any type of computer can run tekXtool application once compiled from C files and their libraries.Albert

author: madao
author_rank: Frequent Contributor
timestamp: January 04, 2020, 09:35:31 am
content: My program skill is not the best for high complex program with pointer and operation in computer w operation system. (only C for µC) I don't unterstand , how functions pointer in C. This is why, i want modify only tektool, every one for one flash type.But, it is possible, i think.Because all flash in tek TDS can be identify by write&read pattern.Code:write <data0x90><addr 0x0000> // flash identify commandread <addr 0x0000> // read manufactur identifyread <addr 0x0001> // read device identifywrite <data 0xFF><addr 0x0000> // reset command(example, Intel 28F016SA = 0x0089, 0x66A0, Intel 28F010 = 0x89, 0xB4, AMD 28F010 = 0x01, 0xA7)We must listen GPIB bus, how look commando. A notice: m<hexdecimal addr & lenght > = read commando , M<unknown> = write command.

author: ragge
author_rank: Regular Contributor
timestamp: January 04, 2020, 10:00:57 am
content: Hi madao,Quote from: madao on January 04, 2020, 09:35:31 amYou certainly have the knowledge to learn how to use C pointers - they are not hard, you will learn it in a very short time.Here is one short tutorial, just the first google hit I got:https://www.tutorialspoint.com/cprogramming/c_pointers.htmQuote from: madao on January 04, 2020, 09:35:31 amAre there Tektronix TDS scopes with the AMD 28F010, or was that just an example?Quote from: madao on January 04, 2020, 09:35:31 amThere already is code for that in the tektool.c:s and tekfwtool.c, and also in getcaldata.c. Just check the code in my repo, they are actually pretty small programs.https://github.com/ragges/tektoolsRegards,Ragnar

author: madao
author_rank: Frequent Contributor
timestamp: January 04, 2020, 10:09:33 pm
content: I have a TDS520 with mixing (yes it is cocktail w intel & amd flash, it was tek factory repair) of intel & AMD 28F010. Friends from me has a TDS540 with AMD-flash. Dead TDS540A has AMD 28F020. Good news: AMD Flash use same erase & program algo as intel's flash.Indeed, i 'll reading your link. but: pleas don't demand me to use pointers. I have tried a few times to unterstanding pointers. without sucess.

author: ragge
author_rank: Regular Contributor
timestamp: January 04, 2020, 10:12:01 pm
content: Quote from: madao on January 04, 2020, 10:09:33 pmInteresting, thanks!Ragnar

author: madao
author_rank: Frequent Contributor
timestamp: January 05, 2020, 03:10:26 pm
content: Now is spare part (TDS700D CPU, TDS724C Acquisition board) here, i can play with him.I have checked tekfwtool, which i have compiled.Not same reaction. It show percent of reading. Tekfwtool from stackframe.org doesn't show percent by reading.But, it can't erase flash 28F160S5. (error message came qiuck) probably 68k code problem, no mood about computer stuff.

author: ragge
author_rank: Regular Contributor
timestamp: January 05, 2020, 11:06:41 pm
content: Quote from: madao on January 05, 2020, 03:10:26 pmHi madao,So this one can not erase 28F160S5?You mentioned above that the one from stackframe.org could.Since this is in the 68k part (target.bin) - did you recompile the 68k code, or did you take it from somewhere else?Regards,Ragnar

author: madao
author_rank: Frequent Contributor
timestamp: January 06, 2020, 05:46:08 am
content: this c-sourcefile and all file (inlc. target.bin) came from stackframe.org and i have compiled it (it is called tekfwtool0.exe)tekfwtool.exe is orginal and present in same folder as tekfwtool0.exe. Orginal runs, my compiled can't erase & program. read & write -> no problem.I have tektool.c source file form stackframe.org (it is downloaded over waybackmachine). This is wreid, because, GPIB-Device address is 1 and uses "*IDN?" GPIB command, which bootloader of TDS-instrument doesn't replies. This source file is too wrong, i think. After reading of this source file, i have a guess: It works on Instruments after normal start. I will not attached this sourcefile.

author: ragge
author_rank: Regular Contributor
timestamp: January 06, 2020, 05:58:46 am
content: Quote from: madao on January 06, 2020, 05:46:08 amSo 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)?

author: madao
author_rank: Frequent Contributor
timestamp: January 06, 2020, 06:11:49 am
content: 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.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 06, 2020, 07:35:55 am
content: Quote from: madao on January 06, 2020, 06:11:49 amOnce the EXE application generated after your compile, where do you run the tekfwtool0.EXEFrom floppy disk drive) or from your PC computer connected to a GPIB-USB interface to the TDS oscilloscope ?Albert

author: madao
author_rank: Frequent Contributor
timestamp: January 06, 2020, 09:41:30 am
content: 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 0000Quote from: madao on January 04, 2020, 09:35:31 amIt 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.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 06, 2020, 11:15:06 am
content: Quote from: madao on January 06, 2020, 09:41:30 amYes 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 repositaryhttps://www.eevblog.com/forum/repair/gpib-usb-control-between-macbook-air-(macintosh)-and-tds540c/msg2856510/#msg2856510Quote from: madao on January 06, 2020, 09:41:30 amLet'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

author: madao
author_rank: Frequent Contributor
timestamp: January 06, 2020, 11:31:20 am
content: Quote from: Tantratron on January 06, 2020, 11:15:06 amYes, it is my goal, one tools for more flash type. But i'll using my programming stile.Quote from: Tantratron on January 06, 2020, 11:15:06 amDid 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"

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 06, 2020, 04:45:59 pm
content: Quote from: madao on January 06, 2020, 09:41:30 amHelloMatt,Do you confirm having compiled the tektool.c file from ragge github repositoryhttps://github.com/ragges/tektools/tree/master/tektooland could remind precisely what code you have changed " the 0x90 versus 0xFF saga" so it erases properly the 28F160S5 flashfile chipDo you confirm then to have used the tekfwtoolCc file from raggehttps://github.com/ragges/tektools/tree/master/tekfwtoolto program the 28F160S5What do you recommend for my own compiling with MacOS since both my TDS540C has another 28F016SA flashfile chip ?HelloRagnar,I've created a github account for myselfhttps://github.com/tantratronwhere 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

author: madao
author_rank: Frequent Contributor
timestamp: January 06, 2020, 05:15:05 pm
content: Quote from: Tantratron on January 06, 2020, 04:45:59 pmYes, 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 OKDid you confirm your compiler know "usleep(xx)"-subroutine ?Quote from: Tantratron on January 06, 2020, 04:45:59 pmtektool.c from ragge's github, not tekfwtool.c

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 06, 2020, 05:38:31 pm
content: Quote from: madao on January 06, 2020, 05:15:05 pmLast week and until now, I've only compiled and run native MacOS the tekfwtool modified by Ragge herehttps://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 repositoryhttps://github.com/ragges/tektools/tree/master/tektoolto 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.

author: Galen
author_rank: Regular Contributor
timestamp: January 07, 2020, 05:41:55 am
content: 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.

author: Galen
author_rank: Regular Contributor
timestamp: January 07, 2020, 05:48:10 am
content: 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.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 07, 2020, 06:11:07 am
content: Quote from: Galen on January 07, 2020, 05:48:10 amDoes anybody has the complete C files and H files of tektool_0 so it could be generalized t Linux and MacOS ?Thanks, Albert

author: Galen
author_rank: Regular Contributor
timestamp: January 07, 2020, 08:52:04 am
content: Quote from: Tantratron on January 07, 2020, 06:11:07 amNot in the zip. let's see if anyone have it.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 07, 2020, 10:15:10 am
content: Hello Matt,Could explain why the proper way to erase the flashfile memories involves this LENGTHCode:tekfwtool -e -b 0x01000000 -l 0x10I 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

author: ragge
author_rank: Regular Contributor
timestamp: January 07, 2020, 11:24:18 am
content: Quote from: Tantratron on January 07, 2020, 06:11:07 amWe 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

author: ragge
author_rank: Regular Contributor
timestamp: January 07, 2020, 11:25:59 am
content: Quote from: Tantratron on January 07, 2020, 10:15:10 amWhen 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

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 07, 2020, 11:32:12 am
content: Quote from: ragge on January 07, 2020, 11:24:18 amhello again Ragnar,Maybe you have not noticed this specific thread where this is the last updatehttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2860746/#msg2860746I 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

author: ragge
author_rank: Regular Contributor
timestamp: January 07, 2020, 11:57:42 am
content: Quote from: Tantratron on January 07, 2020, 11:32:12 amHi 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

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 07, 2020, 12:20:25 pm
content: Quote from: ragge on January 07, 2020, 11:25:59 amOk 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.

author: ragge
author_rank: Regular Contributor
timestamp: January 07, 2020, 12:28:58 pm
content: Quote from: Tantratron on January 07, 2020, 12:20:25 pmFor 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

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 07, 2020, 12:36:46 pm
content: Quote from: ragge on January 07, 2020, 12:28:58 pmI hesitate to use the floppy getcal EXE or the getcaldata C file then compile in my Macintosh because inside commentshttps://github.com/ragges/tektools/blob/master/getcaldata/getcaldata.cmention 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

author: ragge
author_rank: Regular Contributor
timestamp: January 07, 2020, 12:49:21 pm
content: Quote from: Tantratron on January 07, 2020, 12:36:46 pmI 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

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 07, 2020, 01:04:23 pm
content: Quote from: ragge on January 07, 2020, 12:49:21 pmYeap 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... seehttps://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2856798/#msg2856798However 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.

author: ragge
author_rank: Regular Contributor
timestamp: January 07, 2020, 01:07:34 pm
content: Quote from: Tantratron on January 07, 2020, 01:04:23 pmYes, 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

author: madao
author_rank: Frequent Contributor
timestamp: January 07, 2020, 02:41:17 pm
content: 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.Greetingsmatt

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 07, 2020, 02:54:49 pm
content: Quote from: madao on January 07, 2020, 02:41:17 pmI think you meant 0x408 0000 but maybe I'm wrong ?

author: madao
author_rank: Frequent Contributor
timestamp: January 07, 2020, 03:05:44 pm
content: Quote from: Tantratron on January 07, 2020, 02:54:49 pmYou're right. !

author: ragge
author_rank: Regular Contributor
timestamp: January 07, 2020, 03:14:42 pm
content: Quote from: madao on January 07, 2020, 02:41:17 pmMatt,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

author: madao
author_rank: Frequent Contributor
timestamp: January 07, 2020, 03:22:40 pm
content: 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.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 07, 2020, 05:07:11 pm
content: Quote from: ragge on January 07, 2020, 11:57:42 amGood evening Ragnar,Proud and happy to confirm that your newtekFWtool repositoryfirst compiled then run on myMacBok Airhas successfullyerasedthe flashfileE28F016SAof my TDS540C to remove V5.0.1e thenflashedv5.2e firmware.I'm using aGPIB-USB-HS interface of National Instrumentsbetween 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

author: ragge
author_rank: Regular Contributor
timestamp: January 07, 2020, 05:46:22 pm
content: Quote from: Tantratron on January 07, 2020, 05:07:11 pmI am happy to hear that, thank you very much for testing!Best regards,Ragnar

author: madao
author_rank: Frequent Contributor
timestamp: January 07, 2020, 06:27:07 pm
content: HiI 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 1I 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.bingreetingsmatt

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 07, 2020, 06:38:20 pm
content: Quote from: madao on January 07, 2020, 06:27:07 pmHello Matt,This afternoon when I test the programs update of Ragge, I did compile with success then run the erase withtektoolbut did not like the fact many displays, scrolling so I lost the track. So I thought to rather compile and runtekfwtoolwhich 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 prefertekfwtool.Do you know what is the latest firmware for C series... v5.0e v5.2e or more recent for TDS540CBy 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.

author: madao
author_rank: Frequent Contributor
timestamp: January 07, 2020, 07:36:40 pm
content: 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 :-)QuoteDesoldering & 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.greetingsmatt

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 08, 2020, 05:03:09 am
content: Quote from: madao on January 07, 2020, 07:36:40 pmNo 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

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 08, 2020, 07:17:03 am
content: Quote from: madao on January 07, 2020, 07:36:40 pmI 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

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 09, 2020, 07:32:43 am
content: Quote from: madao on January 07, 2020, 07:36:40 pmI 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

author: madao
author_rank: Frequent Contributor
timestamp: January 11, 2020, 07:48:22 am
content: 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-vv52.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.

author: madao
author_rank: Frequent Contributor
timestamp: February 01, 2020, 02:38:32 pm
content: Success with programming of TDS540Also success by TLS216 with 28F008SAI must check with TDS744 (with AMD 28F020). /It is not fast, but it functions.

author: ragge
author_rank: Regular Contributor
timestamp: February 01, 2020, 05:44:49 pm
content: Quote from: madao on February 01, 2020, 02:38:32 pmHi 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

author: madao
author_rank: Frequent Contributor
timestamp: February 01, 2020, 06:49:50 pm
content: Hello ragnarI 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.

author: ragge
author_rank: Regular Contributor
timestamp: February 01, 2020, 08:04:31 pm
content: 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

author: madao
author_rank: Frequent Contributor
timestamp: February 02, 2020, 08:24:14 am
content: 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)

author: ragge
author_rank: Regular Contributor
timestamp: February 02, 2020, 07:43:41 pm
content: 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.

author: madao
author_rank: Frequent Contributor
timestamp: February 02, 2020, 08:24:00 pm
content: 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.

author: DC1MC
author_rank: Super Contributor
timestamp: September 24, 2021, 08:29:20 am
content: 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

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 05, 2023, 05:02:16 pm
content: 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 repohttps://github.com/ragges/tektoolswhere unless I'm wrong, the original come fromhttps://github.com/fenugrec/tekfwtooland herehttps://github.com/svenschnelle/tekfwtoolplus 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 herehttps://github.com/tantratron/tektoolswhere I've been always using National Instruments GPIB-USB and Macintosh computer.Thanks again ,Albert

author: fenugrec
author_rank: Frequent Contributor
timestamp: January 07, 2023, 09:46:00 pm
content: Quote from: Tantratron on January 05, 2023, 05:02:16 pmNote : 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.

author: Tantratron
author_rank: Frequent Contributor
timestamp: January 11, 2023, 03:14:17 pm
content: Quote from: fenugrec on January 07, 2023, 09:46:00 pmStrange situation of github owners forking and re-forking or posting source code not fully compiled or checked.As for ragges github tektoolSrepohttps://github.com/ragges/tektoolshis 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.