SWAPPED CARDS BUT ISSUE REMAINS AT BIT 14
The issue is somewhere from the pins of sockets L2/L3 in gate B compartment B1 of the 1130 out to my 1130 MRAM core memory replacement board. I continues to be intermittent, but fails on the order of once every few hundred accesses. I also find that bit 10 continues to fail but that might be one time for every few dozen times we stop with a bit 14 error.
I resoldered all the leads and components on my PCB that are involved in handling bit 14 - no change in the results. I examined the backplane where the card for that bit plugs in (L3) and noticed that a wire wrap connection was made from the T4 cable connector on top down to the pin where the sense pulse for bit 14 is connected to the card. That connection should already exist on the backplane, so the added wire seems redundant unless it is fixing a defect in the board. If there was a defect it might have spread a bit.
Oh no, you might have had a defect in the backplane all the time? Oh no X2. Hey, my father once said "the good engineer always is searching at his own stuff for the error". And you did that to the extreme :D Also, happy to see you are putting the DSLogic to some work. I hope you get used to the software. For the price point I like that thing a lot :)
ReplyDeleteI do like the DSLogic, actually easy to use. I probably should use it more often than I do, but somehow it just seems like it will be quicker and easier to put the oscilloscope on four signals that to collect 16 at a time with the DSLogic.
ReplyDeleteThe scope does show analog issues that might be obscured on the logic analyzer, but I spend too much time swapping the four probes around trying to find the misbehaving signal sequences.
I have redesigned the PCB multiple times, changed the parts and approach several times and put quite a bit of effort into ensuring a very solid ground and power plane. While it did banish the spurious retriggering it never made a more consistent turn-on of the SBR bits.
I always look to my design, or in some cases to wrong assumptions I have about the way it will interact, but when you change so much yet the issue doesn't change it has to raise suspicions of an external flaw.
Yes, the 1130 had been working but the core stack was failing over that time leading to quite a few parity errors. Each time I had a confirmed broken connection on the stack, I could resolve that, but it is indeed possible that I was simultaneously seeing some sporadic failures I attributed to the core stack that might have been the cause of my current issues.
Until I have a definitive cause, one that makes sense and one that I can completely resolve, I have to keep looking and trying things in every place I can imagine.