Image Map Image Map
Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: H11 (LSI-11) Troubleshooting

  1. #1

    Default H11 (LSI-11) Troubleshooting

    All --

    As discussed in another thread of mine in the Hardware section (http://www.vcfed.org/forum/showthrea...Supply-Repairs) about the power supply failing, there seems to be other problems that the supply failure may have caused.

    For background, the system was working about 6 months ago and I pulled it off the shelf to use it about two months ago, which is when the power supply failed. The system contains the LSI11 CPU, two 16k RAM cards, an Emulex UC07 SCSI card and two Heath-made SLUs.

    When I start the system in HALT, the below is what I get on the terminal. After it prints, the terminal is non-responsive (meaning, it won't accept any input). I have also reduced the system to the CPU, one RAM card and the primary SLU and I get the same output.

    >
    177777
    @7v?
    @?
    @?
    @w?
    @6?
    @?
    @

    Based on this, I'm wondering if the LSI11 card (M7270) got zapped during the supply failure, but I don't have a spare to test it against. Any thoughts or guidance would be helpful and appreciated. Thanks!

    Rich

  2. #2
    Join Date
    Apr 2017
    Location
    Switzerland
    Posts
    192

    Default

    Hi,

    Did you try with only the CPU and the other SLU?

    Peter

  3. #3
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,009

    Default

    Just beat me to that!

    You should also be able to run in ODT without any RAM card if I remember correctly.

    Dave

  4. #4

    Default

    Peter/Dave:

    Yes, I did try that and I get no output on the console. The only way I get characters on the screen is with a RAM card inserted. I tried both the Heath-issued 16K (which was in the system when it failed) and a DEC M8044 32k board I had on-hand (which was never used). I also noticed that I don't get the "RUN" light when I toggle from HALT to RUN (I need to re-check that circuit but IIRC, it tested fine when I re-qualified the power supply -- it's part of the check-out procedure in the Heath manual).

    Rich

  5. #5

    Default

    Quote Originally Posted by RichCini View Post
    Peter/Dave:

    Yes, I did try that and I get no output on the console. The only way I get characters on the screen is with a RAM card inserted. I tried both the Heath-issued 16K (which was in the system when it failed) and a DEC M8044 32k board I had on-hand (which was never used). I also noticed that I don't get the "RUN" light when I toggle from HALT to RUN (I need to re-check that circuit but IIRC, it tested fine when I re-qualified the power supply -- it's part of the check-out procedure in the Heath manual).

    Rich
    It should be possible to get into ODT without RAM. Is the startup jumpers set to HALT or BOOT from 173000?

    I once had a SLU with a bad UART. It was sending 7 bit regardless of board setting. Took a while to understand that. Lately I have had problems with USB dongles. They would work fine under Windows but not under Linux for some reason. Haven't investigated further.

    From the look of the printout the ODT parser in the chip isn't happy with what it received. Could there be some kind of problem with SLU receiver chips which are causing characters to enter rapidly which it doesn't recognise? Or the UART? Is it always EXCATLY the same sequence of characters?

  6. #6

    Default

    Mattis --

    I'm going to be traveling the next couple of days so I won't be able to get back to this until Friday, but the LSI11 is configured to always boot to ODT and the RUN/HALT switch is set to HALT. I also noticed last night that the RUN light wasn't coming on when I switched to RUN so I need to double check that (it did pass the test when I fixed the power supply but I want to run through it again).

    Regarding the console SLU, it was always set to 4800,8N1 and worked just fine. I did swap the UAR/T but I need to make sure I did it on the right board. The characters returned are generally the same, but I'd have to look at it more closely.

    So, a few things for me to double-check when I get back.

    Rich

  7. #7

    Default

    Ok, I had a few minutes to check some things out. I swapped UAR/T chips with a new 6402; no difference in output. The ODT will not come up unless there is RAM installed. The character sequence that's on-screen is similar, but not exact, each time I reset it. It starts with 177777 followed by 9 or 10 lines starting with the "@" prompt and various characters but each no longer than 2-3 characters long. The RUN/HALT light is off regardless of switch setting, so I need to check into that when I get back.

    Maybe this provides some needed clues.

  8. #8
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,009

    Default

    Rather than swap the UART chips, why not just swap the entire serial board (if you have two of them)?

    This should rule out the entire serial board at least.

    This is certainly a strange fault...

    I suspect where it prints a ? Followed by a <CR> followed by the '@' prompt; ODT has received what it thinks is an illegal character (as far as its syntax is concerned). It does look like some sort of serial fault to me, or at least that's the track I would follow until proven to the contrary.

    Dave

  9. #9
    Join Date
    Nov 2014
    Location
    Chicagoland
    Posts
    160

    Default

    You might want to check and disable the "Halt on Break" (framing error action) on the console board to rule out effects from serial input faults.

    Next as Dave suggests, I would swap out the serial boards as provided you jumper the spare to match the console address of the original.

    If that doesn't help, then I would start with checking the basic backplane voltages and signals (BDOCK, BPOK, HALT, BVENT) with an oscilloscope.

  10. #10

    Default

    I worked on this a bit today and here's what I observed:

    o Took the secondary SLU and re-jumpered it to be the primary. The test results were different, but similar to the first. So, upon DC_ON, I get 177777 and the at-prompt, a pause of a second or two, and then a stream of garbage like the last time, but much longer. Disabling the framing error halt had no effect.

    o The system will still not get to that point without a memory board installed.

    o The HALT-RUN flip-flop checks out, but the LED doesn't go on when toggled. I checked the signal path to the bus and it's fine, as is BPOK, BDCOK and HALT. The SRUN signal doesn't change when the HALT switch is toggled. The BVENT signal is not particularly stable. I can say it's nowhere near 60Hz. I may replace the drive transistor for it and see if that helps but I may trace it further back to the power supply and see if a diode or something is blown.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •