HTML-код
- Опубликовано: 9 апр 2022
- The backup went good, i think, but the DALLAS was so old i could not be reprogrammed. i KILLED iT. Now looking for the replacement set.
www.eevblog.com/forum/repair/...
w140.com/tekwiki/wiki/TDS744A
www.eevblog.com/forum/repair/...
NVRAM kit: www.ebay.com/itm/302913384290
GPIB_ISA go.tonyalbus.com/GPIB_ISA
GPIB_ISA go.tonyalbus.com/GPIB_ISA_2
GPIB_PCI go.tonyalbus.com/GPIB_PCI
GPIB_PCI go.tonyalbus.com/GPIB_PCI_2
GPIB_Cable go.tonyalbus.com/GPIB_Cable
GPIB_Cable go.tonyalbus.com/GPIB_Cable_2
HP 82357B CN: www.aliexpress.com/item/40000...
#TDS744A #tektronix #nvram #dallas 
Наука
![CENTRAL CEE - GEN Z LUV [VERTICAL VIDEO]](http://i.ytimg.com/vi/VIbidJm9q34/mqdefault.jpg)
Yeah. Typical example. Don't fix it if it's not broken 🙃 But we all have learned a bunch from your experiments... and you do what you like. thanks! I am also in a doubt, to buy this kind of scope for a few hundred or to buy a brand new "Siglent like". Some oldies can have more performance for the buck, but then again if they are at the end of their bathtub curve then it would be waisted money. But I am also a bit nostalgic at the age of 50 about the old equipment so that has some value too. 😀
Thanks Ernest, yes you are correct, some powerful tools for your money, but i am not sure i would do it again, the scope was not cheap, then the 2 Dallas replacements and now because i am stuck, i have a spare mainboard, and at some point the CRT and PSU will go. all thing added i prob could have bought a great new fast scope. But yes nostalgia and this whole experience is also worth some for sure. i am not giving up yet :) it is still an amazing machine!
These Dallas chips can be read with an EEPROM programmer. You then want to find a pin-compatible FRAM and store the copied data into that FRAM. Put the FRAM in place of the Dallas chip and you're done once and for all.
Yes indeed. thank you
Hey Tony, het was een interessante maar ook riskante exercitie. Jammer dat het mislukte en hopelijk dat hetgeen je gevonden hebt nog gaat werken. 👍🏻
Dank je, ja beetje slecht over negedacht.. was ook wachten tot die chips er mee stoppen...
I Tony, The corrupted address comes from EEPROM 28F020 data, you can use a .bin file editor to compar the downloaded file with a good 1.1E original file. Compar the data at adress 0x000003 between downloaded file and orginal file.
Afterward, you can reduce the length "-l 0x300000" to""-l 0x300" to stop the flashing before the end, to save time.
You can clear all flash by the command "tektool -p -b 0x1000000 -l 0x10". You can use your compute with the PCIIA card, this will give better results for downloading the firmware without error.On my TDS744A now calibrated TDS84A :) The two NVRAM are use to save the options (1F...), curves, time, but not the calibration factor. Calibration factors are on two EEPROM on acquisition board. Good luke, Hacks these oscilloscope gave me a lot of pleasure, but its took several week end of my time. Vincent
Thanks! will sure try
Like the wood rack!
Thanks, here is the build. ruclips.net/video/ZDfbFB5v4Y4/видео.html
@@TonyAlbus - Watched it!
Very nice 👌
Thank you!
Hi Tony, great video as always. Can you post a link for the DOS tektool version you used?
TIA
i think you can find it in the TekWiki in the link below the video. i will also post it in my next video about the 744 when i have received the new board
Good attempt Tony. Pity the scope wouldn't program. Could it be the NVRAM hasn't got the available space in memory?
Thank you Simon.. i gives a write-error on adress 000000003 .. that is at the start, i am a bit afraid one of the NVRAM is broken. i notices with the writing zero's . it needed lot of retries.
I've found that sometimes the older ones will reprogram if you just try a few times, but by that point, it's due for the bin and new NVRAM time....
It looks like yours is well dead though.... Too bad, time to warm up the soldering iron!
Yes will order from ebay from that EEVblog member from Texas, he seems to do honest business
If only there was a way to do this on my 2565B. I have a backup I acquired from Israel with the basic cal data when the original fails. Batteries embedded in epoxy? I think when many companies used the Dallas modules they were only concerned with the average life expectancy/book value of test gear. The issue isn't just limited to TEK products either Tony. What a shame.
Yes a shame, i also need to do a backup of my Marconi, good one!
It is possible to use an EPROM programmer to copy out your module along with calibration data.
The batteries are embedded in epoxy, but it is possible to cut it open if you have a LOT of patience and a VERY steady hand...
Usually easier and more reliable to hit ebay for one of the replacement reproduction modules.
@@TERRAOperativeOriginal Thank Jared
Hi Tony, great video as always. Can you post a link for the tektool you used?
TIA
Hi Gulio, thank you. i will make a new video soon when i receive my new secondhand mainboard, i will post it in the links below the video. but i think you will also finf it in the TekWiki, i have a link in this video description
@@TonyAlbusTony I know you bricked your scope and this may help, I was able to bring my TDS754C back to life after bricking it, and change the firmware from 5.1.1e to 5.3e but had some problems before doing so. Here is what I started with and did,
Using Windows 11 pro, Agilent 82357B, Keysight Connection Expert, first thing I did is to back up the VNAM and original firmware, then wrote the VNAM to see if it was indeed writing and it did because the date changed back to the image file I had, then wrote the latest firmware 5.3e, flipped the switch back to protected then restarted the scope... it was bricked. Here is how I was able to recover from bricking.
1.)clear of firmware
put of string "tektool -e -b 0x1000000 -l 0x10"
2.)flashing of firmware (I decided to double down and go for the same and new 5.3e firmware)
put of string "tektool -p example.bin -b 0x1000000 -l 0x400000"
3.)VERY recommend: Switch unit off and on, before verify of firmware. Pleas wait 10 seconds after power-it , then switch protect-switch to "protect" for safe verify.
4.)verify of firmware (VERY recommend)
put of string "tektool -v example.bin -b 0x1000000 -l 0x400000"
5.) Re start the scope and it was updated to 5.3e, all seems to work just fine. 🙂
so if you don't have a correct backup of your original firmware try to write a newer firmware that pertains to your scope on the address range that is correct and see what happens, then for good measure write the VNAM also. Hope this hepls.
@@juliohormilla3862 Thank you very much for taking the time to help me, those are great tips, that i will try for sure, thanks mate!.
@@TonyAlbus BTW, I never experienced the re-tries that kept popping up while you were writing the firmware, not sure what could cause that? Wrong address ranges? Timing?
@@juliohormilla3862 The re-tries were because my DALLAS chips were already bad. i have changed those with the modern replacements. The other mainboard arrived today, so maybe i play this weekend.
👍
Thank you!
I don't like when this happens, this is why I am so afraid when updating any firmware, because theese things can easily end up in brickboxing that device. First thing. When reading content of some ROM, do it twice or three times and then compare results. You should get three identical files, otherwise there is something terribly wrong with that backup procedure.
I found some 744A firmware and looked into it using some weird tools and. If I look at the begining, there is an copyright message. This has nothing to do with the whole system, but gives you usefull hint how the whole memory is organized. I've found copyright message with every letter repeated four times, which leads me to the conclusion, that four of 28F020 are tight together to form a 32bit data bus (Copyright message would appear in any of them.) We know, that 28F020s are 256k×8, so four of them form 1MB memory, so boundaries of the fourths of that chips would be at 0x100000, 0x200000, 0x300000 etc. The second important thing is that area between 0x2B9A98 and 0x399999 is filled with 0xFF, which is nothing more than a unprogrammed flash or unused addresses (if the data bus is pulled up to high), which leads me to the second conclusion. There are 3MB or 4MB files, but the memory behind 3M is not used at all, so there is no need to programm it. And if there are 3Meg and 4Meg version of that scope. How "clever" is that programming algorithm? What happens when you try to programm some address, that is out of the Flash memory boundaries? In fact, 28F020 are easy to read, they behave just like an EPROM, but it is not easy to write into them, there have to be implemented some special protocol to do this, and implementation of it could be weak without range checking and things like that, so programming outside the Flash boundaries could result in unpredictable things, like corrupting the content of the flash.
And this is what I'd like to suggest you. Take some binary editor and look at the original firmware downloaded from that scope. (Make a copy of it before touching that file.) Try to find the real end of the programmed data, there will be something followed by a huge portion of 0xFF data, which indicates the blank flash memory. As you find the point, where the data ends and 0xFF begins, truncate the file at this point and programm only the data part with appropriate -l parameter (idnk where the lenght of the programmed data is taken from, this is why I suggest the truncating of that file, just to be sure, maybe this is not needed and the -l to the address of the end of data is enough). Just programm the firmware into the scope, then turn it off, swap that update switch to "protected" and turn it on. Skip that erasing step, skip that verify step, I don't think they are needed and skip also programming that configuration (Dallas) memory. Maybe the scope will tell you there is something wrong with that memory, but imo, it should (at least) boot up. Then you can correct that Dallas thing, but the first step is to get the firmware back and working.
If this doesn't help, then try to programm the flash as described above and then read it back the same way as you backed up the firmware. Then compare the obtained file with the original one. Does they differ? And if differs, are they somehow offseted? Or how they differ? This could give you some clue how to solve the whole issue.
Thank you very much, wow! that is some serious good information, thanks you for sharing, realy helpful.