Unibone debugging Question

[Jay Jaeger]

I finished my unibone.  Things are not well, and so I have a couple of very basic questions about the tests.

An example error:

Highspeed "moving ones" in register latch 2, stop with ^C.
pass 3 test_register_simple_pattern(2, 2): wrote 0x8, read 0x0
Signal path for bus latch 2, bit 3 (mask 0x08):
  Write: P9.28 -> J10.4 DATOUT_3 -> U10.08 -> U10.09 -> U11.05 -> U11.04 -> A03
  Read : P8.44 <- J17.4 DATIN_3 <- U09.15 <- U09.05 <- U11.06 <- U11.04 <- A03

And indeed, if I manually write 0x0 to register 2, A00 - A07 are UNIBUS 0, and if I write 0xff to register 0, A00 - A02 and A04-A07 are UNIBUS 1, but A03 remains at UNIBUS 0, confirmed both by voltages and the UniProbe installed as one of two terminators on the backplane.

After running the test, I supposed that things are left in the state of the test except for the latch select L and write lines, correct?  (And therefore this would mean J10, J15 and J17 would not be the same as they were at the time of the error, correct?)

Assuming that, I supposed that the latches should *still* contain the values at the time of the error, correct?

The board is in a 9 slot DD11 (I checked to make sure it was "ordinary" and not a special purpose backplane.  5V supply is spot on.  Terminators are a UniProbe and a M903.  This error was present with just the M903 as well.

The test fails consistently.  (Indeed, I have problems on most registers except 5 and 7 which test perfectly).

A12 works correctly, so that would seem to exonerate the BBB PRU inputs and outputs for bit 3, correct?  (Register 3 has issues on A08 and A15 as bit "picks" - but that is another story for another time.)

This presumably also eliminates the possibility of issues with REG_DATIN and REGDAT out lines, which are shared amongst all of the signals.

I swapped U11 and U12 and the symptoms did not change, presumably exonerating the two 8641 UNIBUS driver chips.

So I believe that pretty well narrows it down to U10 and U9, as having an open a short or a bad chip.

So, am I right in guessing that, aside from visual inspection and perhaps measuring for shorts and opens, I will need to 'scope this thing (or use a logic analyzer) to see what was really going on?  Ideally I would trigger on the appropriate SELECT line but that is a pain, because those don't seem to be broken out on the UNIBONE, but I could probably just trigger on REG_ADR2, yes?

JRJ

[Joerg Hoppe]

Jay,

some unsorted ideas ...

- I'm not sure wether the displayed signal chain
    (" Write: P9.28 -> J10.4 DATOUT_3 -> U10.08 -> U10.09 -> U11.05 ->
U11.04 ..")
    is correct for your board. Better trust the schematic only ... you
have 2019-12 ?

- keep in mind the high speed test is a GO-NO GO which also tests the
backplane and terminators.
The old DD11 backplane is also a frequent source of errors. Contact
failures may be intermittent.
 Its a big help you have  the Uniprobe for the real bus state.
 But: verify Unibus signals on the Unibone itself are correct, not just
the Uniprobe LEDs.

- Don't use the high speed latch test for now, exercise UNIBUS lines
statically one-by-on in the "bs" menu.

-  Best to test the "read" signal chain first, then "write".
  For read: Set some signals on the Unibus to active = GND, then read
the latches/refresh the signal display.
- To test BG4,5,6,7 and NPG signals, the Grant chain to the termiantors
must be closed.

-  For soldering errors: most critical is the BeagleBone plug adapter.
Beep all 92 pins from the PCB to the Beaglebone.
Bend the PCB with plugged-on BeagleBone a bit while the high speed test
finally runs ... the test should continue.

- Are the plug-in resistor packs correct?

- For your specific questions:
You see a wrong A03 when writing, right?
Other "bit 3" signals on "PRU output bit3" REG_DATOUT_3 are (see schematic):
BG7_OUT, BR7, A03, A11(not A12!),C1, D03, D11,INIT
Are all these defect in the "bs" menu?

- Agree: if swapping the DS8641 doesn't change the problem, they are OK.
But the DS8641 sockets may have a solder problem.

- For bitsavers M903 isn't a terminator, but a cable adapter, see
http://www.bitsavers.org/pdf/dec/modules/mSeries/M903.pdf

- Failures on the Uniprobe may also cause permanent UNIBUS errors.

[Jay Jaeger]

One down:  This *particular* problem was a solder bridge on U10 between pins 9 and 10.  Register 2 now works correctly.  ;)  On to the rest.

[Jay Jaeger]

Yes, 2019-12

So far, nothing has pointed to issues on the DD11.  I manually checked ("beeped") all the address and data lines, and the BR/BG/MSYN lines.  (I have yet to put some jumpers in place in a couple of slots where the NPG jumper was cut.)

I tested my UniProbe on my PDP-11/24 a few months back.

I have been using tl with individual register sets and reads as a static test - didn't see the "bs" test, but will look at it when I take this up again - may be in a couple of weeks.  So far I have fixed register latches 2 and 4, and most of 6.  6 seems to have a non-static issue on a single bit - static tests work, but walking "one" and other tests fail.   One solder bridge, the rest look to be cases where I didn't use enough paste when I flowed the chips.

Because of how I constructed it, using through-hole pin headers rather than the solder-through method on your website, those are all fine - I had "beeped" them when I put it together.

Of course the BBB itself can also fail, especially my used one, but I checked it out manually before I built the board, months ago.   

 

The resistor packs are all per the schematic.  I am actually using jumpers for RN10.

M903 was a mis-transcription.  It is, of course, an M930 terminator.

JRJ

--
You received this message because you are subscribed to the Google Groups "UniBone" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unibone+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/unibone/30611c54-51a1-ba55-03f2-ba7c9c8a90f8%40gmail.com.

[Jay Jaeger]

I got the problems "sorted" as the brits like to say.   Random test has been running fine for 10 minutes now.  Plan to let it go a couple of hours.

Two cases of a solder bridge (one was tiny, and caused that "slow" bit on register 6.  The others were just not enough solder paste when I flowed them (including one on a select line).  

UART2 isn't responding, though, for some odd reason - will need to see if that is a BBB or board issue.

(BTW, a reminder that because of the "yellow" jumpers in place to "wrap" BG4-BG7 and NPG, the grant chains don't have to be there to test the board itself.)

Won't get to testing memory for at least a couple of weeks - and may need to acquire a power supply to do that.  ;)

JRJ