TDS744A: Hangs with 7-segment code ".L" or segment 'f'

[mssbid]

When starting my 744A with all DIP switches (S1001) set to close (0b 0000 0000),
it runs through the usual procedures which normally end in segments 'e' and 'f' flashing
alternately when all is fine. Now, after turning off the front panel LEDs, it stops showing
code ".L" (see pic 744A_with_diag.jpg).
 
When setting S1001 to 0b 0000 0100 (do not execute diagnostics) we see 'e' and 'f' toggle
2 or 3 times but then only segment 'f' stays on permanently (see pic 744A_no_diag.jpg).
 
In both cases ".L" can be seen occasionally for a few 100 ms during startup procedures.
Don't nail me down on this but I think this wasn't the case earlier.
 
So does anyone know what ".L" means? The dot means that some test has failed but
no idea about the 'L' (it's not in the Service Manual).

[TERRA Operative]

That's a weird one. You are correct that .L isn't in the service manual, attached is the page detailing the error codes.

Is there any way you could make an adapter (or buy one from here) to attach the serial/parallel PCB to the console connector on the main PCB? (The edge connector to the right of the connector the serial/parallel PCB is normally connected).
That way you can hook it to a terminal emulator on your PC (set to 9600 Baud, 8N1 with RTS/CTS flow control) and see the boot messages etc and it'll give us a much clearer idea of what's wrong.

[mssbid]

That's a weird one. You are correct that .L isn't in the service manual, attached is the page detailing the error codes.

Yes, that's why I was asking here. Didn't find any reference for '.L' in the whole :-) Internet.

Is there any way you could make an adapter (or buy one from here) to attach the serial/parallel PCB to the console connector on the main PCB? (The edge connector to the right of the

I've already ordered two of them but it will take until they'll arrive. I will check the output and post it here.

[m k]

Can it be a failed ID Register decoder of value b8 or 1d?

[mssbid]

You mean that it's not .L indead but something else and some segments are missing?
Well, I did that "Walk 7 Segment LED" test ( 0b10100010) and all segments were OK...

[m k]

Not missing but off and dot being lsb or msb.

[mssbid]

Sorry, I don't understand what you mean...

[m k]

Last of first error code pdf is ID Register.
There it states that nibbles are displayed.

If that nibble display procedure swaps to alternative mode it can still display the whole 8 bit number using 7 segments and a dot as bits.
Maybe some other machine using the same ID Register display procedure uses LEDs instead of 7-segment display.

[mssbid]

OK, took a while but now I got it:

Code: [Select]

ID Register
The LED displays the A11 DRAM Processor/Display ID in hex: the
most significant nibble (4 bits) first and then the least significant
nibble.

Now I am more lost than before. For this to apply I would expect two hex nibbles
alternating (which would result in a 8 bit "A11 DRAM Processor/Display ID" -
whatever that is) but no ".L".

I have to admit that I don't understand the whole LED thing entirely. We have

Code: [Select]

Table 1–26: Troubleshooting Procedure For LED Display

and

Code: [Select]

Table 1–28: A11 DRAM Processor/Display LED (DS1)

which are almost identical apart from that funky "ID Register" in table 1-26 and
some additional stuff in table 1-28.

I think I will have to wait for the console adapter and see if this reveals anything...

[Tantratron]

I do not possess any non-suffix neither A or B serie oscilloscope. My return of experience is only TDSxxx/C/D serie.

As for the 7 segments display, with C/D serie if all tests pass then there will be a permanent toggling of upper horizontal segment and lower horizontal segment flashing.

Just for my own info, do you confirm that with TDS744A, once all tests are passed OK then segments 'e' and 'f' will flash ?

Albert

[TERRA Operative]

In my C and D variant units, it's two of the vertical segments that toggle on and off.

[Tantratron]

In my C and D variant units, it's the left side vertical segments that toggle on and off.

Hum, what firmware do you use with your Cs and Ds, what TDS model ?

Very strange because I've tested and/or repaired a total of 7 of these TDSxxx/C/D and all would have toggling on-off between top and bottom horizontal segments !

[mssbid]

Just for my own info, do you confirm that with TDS744A, once all tests are passed OK then segments 'e' and 'f' will flash ?

Normally, when all is (was) fine, segments 'e' and 'f' flash alternately when booting
was done and the device is running. This is what my 784A does and the 744A did
before the error showed up.
 
Now the 744A does what I described in my first post:
 
When enabling diagnostics (leaving DIP switch 3 of S1001 in close position), the
startup ends with ".L".
 
When disabling diagnostics (setting DIP switch 3 of S1001 to open) the startup ends
with 'e' and 'f' flashing alternately a few times and stops with 'f' staying on.
 
See also pics of my first post.

[Tantratron]

Just for my own info, do you confirm that with TDS744A, once all tests are passed OK then segments 'e' and 'f' will flash ?

Normally, when all is (was) fine, segments 'e' and 'f' flash alternately when booting
was done and the device is running. This is what my 784A does and the 744A did
before the error showed up.
 
Now the 744A does what I described in my first post:
 
When enabling diagnostics (leaving DIP switch 3 of S1001 in close position), the
startup ends with ".L".
 
When disabling diagnostics (setting DIP switch 3 of S1001 to open) the startup ends
with 'e' and 'f' flashing alternately a few times and stops with 'f' staying on.
 
See also pics of my first post.

Sorry but I still do not understand how you use then isolate the fault thanks to the S1001 switch, why choose 0000 0100 which does not corresponds to any know self-test choice.

When I try to repair these TDSxxx/C/D (note that I've never had in hands any A or B), anyway I'll first choose 1000 0000 then try 1000 0001, after 1000 0010... to check and isolate individually all sub-systems.

[mssbid]

I made a small video which shows the behaviour without diag enabled.
Since it can't be uploaded here, please check

http://tmp.dyn.g66.org/744a_no_diag.mp4

The alternate flashing shortly before it ends is what would go on endlessly
if all was well...

[mssbid]

Sorry but I still do not understand how you use then isolate the fault thanks to the S1001 switch, why choose 0000 0100 which does not corresponds to any know self-test choice.

When switch #3 is set to close (AFAIK the default), the device runs extensive diagnostics.
This not only makes the startup take significantly more time, it also displays some funky
stuff on the screen.

When switch #3 is set to open, these diagnostics will be skipped:

Code: [Select]

Table 1–27: DIP Switch Options
DIP Selection (8–1)                  Action
...
0100 0100                            Do not execute diagnostics
...

I assume this was made to provide some kind of quick start when powering on the scope.

[mssbid]

I made a small video which shows the behaviour without diag enabled.

Quoting myself :-) Here is the video showing what happens when diagnostics is enabled
(sw #3 closed):

http://tmp.dyn.g66.org/744a_with_diag.mp4

I've read somewhere, that the 7-segment display is mainly used for low-level stuff (like
when the boot ROM still runs). When the "real" FW has started, it only shows segments
'e' and 'f' flashing.

The diagnostics which is controlled by sw #3 is run from the FW. This is the long period
where we see 'e' and 'f' flashing. And in the end it shows ".L" since this error was detected
earlier...

[m k]

.8 1 2 3 4 5(g) 7 8 e [off]
[blinking -] I I- .L [off]
[blinking I] .L [blinking I] .L

"I-" is probably just 'I' where last blink of '-' is visible.
Generally previous value is still lit when next is already present.
'5' has no time to be clean.

Most likely L tries to be meaningful, if so then what, Loop?
Maybe it's simply indicating that something is looping, its earlier blinks can indicate that.
Those blinking segments have also some different timings.

[Tantratron]

I made a small video which shows the behaviour without diag enabled.

Quoting myself :-) Here is the video showing what happens when diagnostics is enabled
(sw #3 closed):

http://tmp.dyn.g66.org/744a_with_diag.mp4

I've read somewhere, that the 7-segment display is mainly used for low-level stuff (like
when the boot ROM still runs). When the "real" FW has started, it only shows segments
'e' and 'f' flashing.

The diagnostics which is controlled by sw #3 is run from the FW. This is the long period
where we see 'e' and 'f' flashing. And in the end it shows ".L" since this error was detected
earlier...

Again and again, as mentioned before you need to use the different S1001 testing positions for looping on each different tests to eventually find out or isolate during the complete sequence what could be wrong, at least find out what works. You are restricting yourself way too much on how the S1001 could help you solve the problem, otherwise let's wait what the Console Port will talk once you'll receive the adapter kit.

Albert

[mssbid]

Again and again, as mentioned before you need to use the different S1001 testing positions

Well, this does not reveal anything. Which is not of surprise since all those tests apparently are
low level tests checking some basic stuff on the processor board (presumably beeing done by
the boot ROM).

Once the OS has kicked in, more diagnostics might be run (or not, depending on SW3). And these
can be observed on the console (using that brilliant adapter from that guy in Italy which arrived now).

With SW3 set to close (execute diagnostics) we get a rather detailed ouput with some interesting
parts:

Code: [Select]

...
calLibrarianDefaultCk .......... pass
dspForcedBus ................... pass
acqProcThermistor ..............ERRORID: 62 hardware error acq processor not responding
 ***FAIL***
..error details:
ERRORID: 151 diagnostic test failure acqProcThermistor
acq processor not responding
** acqProcInit(ACQ_DIAG):  Acquisition processor problem
 
trigGtlRegisterDiag ............ERRORID: 62 hardware error acq processor not responding
 i=0 temp=ffff mask = 7f
 trigReg[i]=8a TRIGgtlAddr = 72c0800
 ***FAIL***
..error details:
ERRORID: 151 diagnostic test failure trigGtlRegisterDiag
acq processor not responding
RegNo: 0x72c0914

fpDiagConf ..................... pass
optDiagPM110Reg ................ pass
optDiagFloppyCacheMem .......... pass
optDiagFloppyControllerIO ......0x51ffea8 (tRootTask): duart portB write timeout, byte: a7
0x51ffea8 (tRootTask): duart portB write timeout, byte: 47
 pass
optDiagFloppyDrive ............. pass
optRS232DuartIO ................ UNTESTED
...
Smalltalk/V Sun Version 1.12
Copyright (C) 1990 Object Technology International Inc.
ERRORID: 62 hardware error acq processor not responding
0x51efec0 (V main): duart portB write timeout, byte: a8
0x51efec0 (V main): duart portB write timeout, byte: 48
0x51efec0 (V main): duart portB write timeout, byte: a8
0x51efec0 (V main): duart portB write timeout, byte: 48
0x51efec0 (V main): duart portB write timeout, byte: a8
...

Thanks to the first error (acq processor) and that famous "component level diagnostics and repair manual"
the rest was simple: The RX line of the 68HC05 on the acq board was quiet while the corresponding TX
line of the UART on the cpu board was not. In the end it was a bad solder joint on that bus board which
connects the two PCBs (the whole area around pin 85 looked suspiciously). After fixing that, the scope
is up and running.

BTW, when setting SW3 to open (do NOT execute diagnostics), the error appears only at the end:

Code: [Select]

...
Smalltalk/V Sun Version 1.12
Copyright (C) 1990 Object Technology International Inc.
ERRORID: 62 hardware error acq processor not responding
0x51efec0 (V main): duart portB write timeout, byte: a8
0x51efec0 (V main): duart portB write timeout, byte: 48
0x51efec0 (V main): duart portB write timeout, byte: a8
0x51efec0 (V main): duart portB write timeout, byte: 48
0x51efec0 (V main): duart portB write timeout, byte: a8
...

So I can confirm what building (or buying) that console adapter is highly advisable and the
7-segment LED should be considered only for that very early low-level stuff. I got attracted
by that ".L", assuming it would represent any failure on the processor board, but I didn't
honour the fact that the OS was up and running already...

[m k]

Maybe one note for casual reader.
Sometimes information is not as thorough as it is here.

Here it is obvious that Thermistor or GtlRegister are not the cause.
It's just that diagnostics happen to report the fault that way this time.

[mssbid]

Here it is obvious that Thermistor or GtlRegister are not the cause.
It's just that diagnostics happen to report the fault that way this time.

Well, it also reports "acq processor not responding". So the probability that it's
really the thermistor is not zero, but rather low :-).

[m k]

Then it would be more like something and thermistor.
Other case could have stopped right after the first fault.

It would also be a bit humiliating if Tek had a cryptic fault diagnostics.

[mssbid]

Then it would be more like something and thermistor.

To be exact, it _is_ more, see "ERRORID: 151 diagnostic test failure trigGtlRegisterDiag"

After fixing the problem, we can also see that diagnostic output has increased significantly.
Here is the diff:

Code: [Select]

...
 calLibrarianDefaultCk .......... pass
 dspForcedBus ................... pass
-acqProcThermistor ..............ERRORID: 62 hardware error acq processor not responding
- ***FAIL***
-..error details:
-ERRORID: 151 diagnostic test failure acqProcThermistor
-acq processor not responding
-** acqProcInit(ACQ_DIAG):  Acquisition processor problem
-
-trigGtlRegisterDiag ............ERRORID: 62 hardware error acq processor not responding
- i=0 temp=ffff mask = 7f
- trigReg[i]=8a TRIGgtlAddr = 72c0800
- ***FAIL***
-..error details:
-ERRORID: 151 diagnostic test failure trigGtlRegisterDiag
-acq processor not responding
-RegNo: 0x72c0914
-
+acqProcThermistor .............. pass
+trigGtlRegisterDiag ............ pass
+trigBtlRegisterDiag ............ pass
+ch1LogicTypeComp ............... pass
+ch2LogicTypeComp ............... pass
+ch3LogicTypeComp ............... pass
+ch4LogicTypeComp ............... pass
+ch1EdgeTrigDiag ................ pass
+lineTrigDiag ................... pass
+dlyTrigDBETrigAfter ............ pass
+dlyTrigDBTRunsAfter ............ pass
+slewrateTrigDiag ............... pass
+trigAttenSerialReg ............. pass
+trigPreampSerialReg ............ pass
+trigDTCSerialReg ............... pass
+trigExtlSerialReg .............. pass
+trigDacSerialReg ............... pass
+TICountersDiag ................. pass
+gtlBigCountersDiag ............. pass
+trigBtlConfidenceDiag .......... pass
+trigGtlCompRamDiag ............. pass
+digRegisterConf ................ pass
+digSpecialRegisterConf ......... pass
+digPhaseLockLoopDiag ........... pass
+digSpeedMemConf ................ pass
+digAcqMemPatConf ............... pass
+digDataFormatConf .............. pass
+digAcqSubSampleConf ............ pass
+digAcqPeakDetectConf ........... pass
+digAcqHiResConf ................ pass
+digAcqMemDataConf .............. pass
+digAcqMemAddrConf .............. pass
+digInterruptConf ............... pass
+digA2DConnectsConf ............. pass
+digHFStepConf .................. pass
+digDspConf ..................... pass
+glitchTrigDiag ................. pass
+pulseWidthDiag ................. pass
+digPixelatorConf ............... pass
+trigNibDiag .................... pass
 fpDiagConf ..................... pass
 optDiagPM110Reg ................ pass
 optDiagFloppyCacheMem .......... pass
-optDiagFloppyControllerIO ......0x51ffea8 (tRootTask): duart portB write timeout, byte: a7
-0x51ffea8 (tRootTask): duart portB write timeout, byte: 47
- pass
+optDiagFloppyControllerIO ...... pass
...

acqProcThermistor and trigGtlRegisterDiag are checked first and during this, the system detects
that it is a communication problem (the cpu does not answer at all), spits out an additional message
"acq processor not responding" and aborts the rest (as it would not make sense to go on).

With SW3 set to close, the scope now needs considerably more time to start. I wasn't aware of that
since I always had it in open position (so that all this diag is being skipped).

[m k]

More messages but no more actual info, if not intermittent is not it.

First acqProcThermistor is tested without an answer.
Since diag continues there can be a Thermistor error with same result.
Next trigGtlRegisterDiag is tested with the same no answer result.
Now diag can assume it's something else since Thermistor and GtlRegister are too different.
It of course can also be just a counter.

[mssbid]

More messages but no more actual info,

I see a lot more actual info. Lots of stuff which wasn't tested before.

if not intermittent is not it.

Sorry, I dont't understand.

First acqProcThermistor is tested without an answer.
Since diag continues there can be a Thermistor error with same result.

A broken thermistor will probably not stop the communication between
the two CPUs. It might come back with 0x00 or 0xFF (or whatever the
ADC range is) but not with nothing.

Next trigGtlRegisterDiag is tested with the same no answer result.
Now diag can assume it's something else since Thermistor and GtlRegister are too different.
It of course can also be just a counter.

Yes, that's possible. It might say: When the first two tests (where the acq cpu
is involved) fail so miserably, there must be something seriously wrong and
decides to not go on. It also might have kicked off trigGtlRegisterDiag before
acqProcThermistor had come back.

Honestly, I don't care ;-) Fact is, that console adapter and these error messages
helped me to find and fix the error within 30 minutes. Before I was too heavily
focussed on that 7-segment display and that took me more than 30 minutes...

[m k]

if not intermittent is not it.

Sorry, I dont't understand.

After two similar incidents they can be treated as one non intermittent fault.
That information was not available after first test so it can be treated as new information.

[mssbid]

After two similar incidents they can be treated as one non intermittent fault.
That information was not available after first test so it can be treated as new information.

Well, if you like... For me the information was already available after the first test, since it
went like a phone call where the other side does not answer (instead of talking nonsense :-)).

It would be a different thing if we had a bus (like I2C or whatever) where it's possbile that
one device is broken and others not. But in our case its a straight serial link with only two
peers and if the remote end does not talk to me regarding a thermistor it won't do that for
other stuff as well (unless the software got confused).

[m k]

For me the information was already available after the first test,

For you yes, but not for the diagnostics procedure.

[mssbid]

For me the information was already available after the first test,

For you yes, but not for the diagnostics procedure.

For the diagnostics procedure as well, but it didn't honour it.