Tektronix Technical Forums are maintained by community involvement. Feel free to post questions or respond to questions by other members. Should you require a time-sensitive answer, please contact your local Tektronix support center here.
It appears as though the Serial / Parallel board has gone faulty and somehow caused corruption of the NVRAM.
The scope will not boot at all with the Serial/Parallel card installed , and although without it - it does boot , but the NVRAM is obviously corrupt.
( Cal initialisation error ).
So - I'm pleading - does anyone have the calibration software - or even a dump of a TDS644A nvram , or the TDS640A nvram.
( For those who followed my scope in the past - it has already been 'capped' )
As an added bonus if I do get the TDS600 series adjustment software - I plan to find a way to get it to run with other gpib options - via DosBox under linux.
( It will require me to write some extra code for DosBox ).
I'm still looking for the TDS600 field adjustment tool if possible.
Alternatively if someone knows the memory locations where the calibration data is stored I could possibly start work on creating my own adjustment software.
For those interested it appears as though capacitor leakage had caused eventual failure of U8 - a dual 2 to 4 line decoder (74F139)
The IC was replaced - the board thoroughly cleaned - and functionality restored.
For those of interest I started to draw the schematic ( the parallel side mostly - and the address decoding ).
I'm curious, what kind of error was your serial/parallel option giving? Or was it just not working? What I've found in the 500A/600A series of scopes is that if you have a serial/parallel option present it automatically finds it and activates it, but if it doesn't find the option it automatically takes it off the option list. Of course, this is with a working serial/parallel option. So perhaps an option board that has a problem actually acts different.
Another question. Did the electrolyte cause the U8 part itself to become defective? Or did it damage a trace to the IC? I've never seen the electrolyte cause any damage to ICs, but I suppose it is certainly possible.
The 7 seg display would flicker between a couple of numbers ( I think 8+9 , but could be something else ).
After lot's of trial and error I eventual found that the scope would boot correctly without the ser/par board.
Unfortunately the scope had then hosed the nvram
I had previously replaced all the electrolytics - but I guess I hadn't cleaned thoroughly the serial/parallel board.
To track down the fault I worked out most of the schematic and decided to eliminate possible options - first I removed the 74F240 ( buffer ) - and the scope would now boot - but the board was not detected.
The errorlog showed an error something like "ERROR: diagnostic test failure optRS232DuartIO, ** addr = 0xe000038 exp data = 0x7f actual ... "
I cleaned around the 74F240 , replaced it - but again the scope wouldn't boot.
Looking at the schematic - the only possibility would be the 74F139 as it was used to directly enable the F240.
Removed / cleaned replaced - still the same fault ( and I noticed the characteristic "whiff" when desoldering the F139 ).
So - replaced the F139 ( actually with an ACT139 ) - and all was well again.
I can only guess that a low resistance path was created by the electrolyte leakage - leading to the death of the F139 - otherwise it was co-incidence.
With the faulty F139 - the F240 buffer was driving the bus all of the time - thus stopping the scope from booting.
Hello,rochoz wrote:Hi Gorgon,
What I've found in the 500A/600A series of scopes is that if you have a serial/parallel option present it automatically finds it and activates it, but if it doesn't find the option it automatically takes it off the option list.
I don´t confirm that.
After power on I get an error with the installed serial/parallel option: Wrong HW configuration error..... with my TDS5** scopes.
It seems to me that the TDS500/600's would kind of choke on the printer option, but if you cleared the error log, maybe tried to power it on with the memory switch in the unprotected mode, then fully power it up, that it would get past this. But maybe I always calibrated them and that cleared this up. I can recal this being an issue but not a problem that would not go away.
On TDS500A/600A I don't recall this being a problem at all. The scope performs a presence test at power on and the hardware is either their or not.
However, if there was a problem where the ser/parallel board was loading the bus (as Gorgon mentions), than that is a completely different problem. I can see where that would cause the scope to not boot up because the NVRAM is on the same bus as the boot code. And although it seems unlikely, I suppose it could corrupt the NVRAM because the CPU would not be allowed to write ANYTHING to the NVRAM other than all 0s for Fs depending on how the 240 was driving the bus. If the CPU was attempting to write a different value to the NVRAM in a checksumed area, it would get corrupted. I don't know how/why the scope would do this, but if the data bus is getting clobbered I supposed it's plausible.
Nice piece of debug work, Gorgon. This is the first I've heard of the electrolyte eating a part, but its good to know.
What model of scope do you have? I assumed you had a 644A, but your most recent post indicates that it might be a TDS5XX scope. In that case, this would make sense.
The TDS640A, TDS644A, and TDS544A will all auto-detect the serial parallel option and will not present an error at boot time when it is installed or missing.
The TDS540 (non-A suffix), on the other hand, acts much different. The TDS540 will give you an error if the serial/parallel option is missing or installed when it's not expecting it. If you have a TDS500 series scope without the A suffix, I would expect the behavior you mention. I would expect the TDS520 or the TDS640 to be similar, but I have never played with one of those scopes in person to know for sure.
I only know this from experience, there is no documentation anywhere that I have ever seen that describes any of this behaviour, its just from my own experience with the different models of this scope.
Who is online
Users browsing this forum: No registered users and 4 guests