| Electronics > Repair |
| Technical TDS540 CPU repair |
| (1/1) |
| vaualbus:
So, for a long time, I have this TDS540 that I found at my university LAB that I was able to acquire. After I replaced all caps but the CPU board does not start and is stuck with a 7 show in the display digit. According to documentation for the TDS544A that mean some kind of BUS error has occurred. Recently I returned at working at this more seriously and I already found a error I made when I clean corrosion is swapped two IC :-DD |O.... One been U1165 that is a kinda important one as it routes the DSACKs signals when the scope enables the addresses outside kernel :-DD. The other is a gate used in the text display part of the board so I think it should not be related to what I am seen. I swapped back the IC to the correct order, very that both still works but yet to my surprise nothing change. PART 1 - The Failure So apparently the technical docs for the TDS544A, even if it uses a way different CPU where a lot of the glue logic has been integrated into some VLSI chips, seems accurate enough to be able to use it for the TDS540 CPU board. According to TDS544A technical docs, the image is attached to the post, we have that the bus control reg is mapped at 0x400000, kernel is mapped from 0x0 and kernel sram is mapped from 0x200000 statusRegs.png (349.28 kB. 903x809 - viewed 35 times.) I developed, basing my work on the tekfwtool, a small emulator (using the syntax that the TDS520 flowchart suggested for the official repair software that is nowhere to be found) that allow me to write/read memory and to branch to functions. I will eventually release it but, as now, it misses all the argument validation code so for now it's kinda bad for general use. I can for example do stuff like: wb 40 0000 0x67, that would write 0x67 to the address 0x400000. I had DIP switch 6 on, so I am entering SDM mode early. When you enter SDM via the NVPROT switch, as is the procedure with the tekfwtool, SDM is enter way later in the boot code after all the bus registers all enabled and access to all the address space is fully enabled. I can use the emulator and poke the memory everything seems to work fine as soon as I stay in the "kernel" space, but as soon as I write bit 7 of the BUS register, that according to docs, enable the BUS to reach memory outside the kernel space, the scope hangs, the _ digit on the display that indicate the SDM mode disappear, and I lost all communication with scope. The boot FW write 0x67 to the BUS registers before try to verify the checksum of the flash memory. I verify that BERR is low so the board it thinks it is in some kind of BUS error and it halt the processor but have no idea why. Unfortunately, we have not the proper TDS540/544 technical reference manul so we have not the equation for the PALs (U182, U1189, U1332) that generate the BERR and DSACK signals. The TDS544A manual skip those table as they are integrated into the VLSI chips. The CPU board as a counter that generate BERR if it is not reset after a given amount of time (Seems 2ms on the sch), BERR is also generated by the interrupt decoder PAL (U1332). I think that I should not care for now about U1332 as it deals with interrupts but those should be activated by se tthe proper bit in the INT regs, but they are accessed from not kernel regs so cannot be accessed before 0x67 is write to 0x400000. (Only two regs are immediately rout and not masked the CONSOLE and the GPIB one, but I think I would not get to this point if any of the two create problems). I suspect that something is not responding on the BUS in enough of time or the DSACK0/1 signals are not correct. I would the counter CHIP that generate the BUS error but that counter is used by a test before the test that write 0x67 to the bus register so I would crash before |O What I don't understand is what should respond on the BUS if I only enable the external bus but perform no read/writes? I hope someone can help me figured out what is wrong, I for sure will need a logic analyzer |O. PART 2 - The BootROM code In parallel I also decompiling the bootrom to understand which commands it accept. Regarding this I really think that the official repair software from Tek did a lot of things. Reading the bootrom it seems that the original tek repair SW(called Repair Environment Diagnostic program) would download code into the scope, modify the vector table and do other "shit" like that and have a lot of the test that SM manual is referring to. These are the commands that the BOOT accept by the way: g, G, m, M, c, s, !, k, d, e, B, U, V, F, A, V from what I can see, low case commands are read commands, upper case commands are write command. For example, m read memory, M write memory, B jumps to an address. |
| vaualbus:
So I did some more investigation and I see that when the scope is in the halt situation (BERRn = 0) it seems that BERRn is not driven by U1054C (that is a NAND placed after the BUS error counter) so that would left only the PAL U1332 to be the primary chip that assert the signal. But I am wondering If I am not going into a red herring :-//, can it be that BERRn is first asserted by U1054C and than while the processor is halted the PAL asserting BERRn low and in the mean time counter is cleared so that it seems that is the PAL that is asserting the signal? I am thinking of this because that PAL should only dealing with interrupts logic generation, and a quick probe around show no different on the input/output before enabling the outside kernel buffers. Only difference is pin 15 but that is correct as it connected to one of the bit you set when you write 0x67 on the control reg. We should really have the PAL truetable but it is only present in the TDS544 technical manual, but I guess If someone has a TDS 540 scope should try read the PAL maybe it is not read protected? Luckily, at least, the PAL is used in a pure combinatorial way as no clocks are present as a chip input (the CLK pin is used as a IO pin) |
| Navigation |
| Message Index |