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
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.
Table 1–26: Troubleshooting Procedure For LED Display
Table 1–28: A11 DRAM Processor/Display LED (DS1)
In my C and D variant units, it's the left side vertical segments that toggle on and off.
Just for my own info, do you confirm that with TDS744A, once all tests are passed OK then segments 'e' and 'f' will flash ?
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.
Table 1–27: DIP Switch Options
DIP Selection (8–1) Action
...
0100 0100 Do not execute diagnostics
...
I made a small video which shows the behaviour without diag enabled.
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
...
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
...
...
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
...
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.
Then it would be more like something and thermistor.
...
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
...
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.
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.
For me the information was already available after the first test,
For me the information was already available after the first test,
For you yes, but not for the diagnostics procedure.