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.
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.
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
One opposite-question: Where did you run tekfwtool? On your MAC ;-)
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
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.
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.
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 ?
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 ?
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.
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
tekfwtool -e -b 0x01000000 -l 0x10
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
Hello Matt,
Could explain why the proper way to erase the flashfile memories involves this LENGTHCode: [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
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
Hello Matt,
Could explain why the proper way to erase the flashfile memories involves this LENGTHCode: [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
Hello Matt,
Could explain why the proper way to erase the flashfile memories involves this LENGTHCode: [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.
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.
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.
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.