 Greetings, RISC-5 friends. I've built a tester. It uses an Adafruit FT232H board, which allows me to hook this up to USB and then send out GPIO or I squared C or SPI or whatever I need. Now I've also used these 40-bit IO expanders, so I have four of them, that's effectively 160 signals that I can send out. And those get connected to the backplane. So now I can test any card that I build by manipulating the signals, sending them out, and reading the signals by reading them in. And there's also a little power connector over here. And if you want to see a little bit more about how I constructed this, there's a live stream where the link is down below. Now I built two of these cards with the intent that one would test the other. So I would output signals from one card and receive them with the other card. And of course, if they match, then the testers test out fine. And a friend of mine wrote a program in order to test the signals. Now each one of these FT232H boards is loaded with its own serial number. And there's a whole set of instructions that I wrote up on how to get this to actually work under Windows 10 and Python 3.6 with the latest version of the FTDI libraries and so on. But in any case, I've written on the board the serial number of which board I've got hooked up to which tester. HT is just the last two characters. There's actually eight characters in the serial number. So what I've done is I've modified the program so that it basically zeros out all bits and then outputs one bit and receives it and then zeros out all the bits and outputs the next bit and receives it and so on. So this way, I'm basically testing every one of the approximately 160 connections. There are a few connections that don't map to the bus. And so let's run the program and see what happens. So as you can see, we're testing the bits and each one of these is one chip. Oh, and we just got an error. So we're just going to, and we got another error. So we're just going to go through all of the signals on all of the chips. So let's take a look at those errors and see what they actually are. So what we're seeing is a failure and this is what we expected. So for U2, so there are five ports of eight bits each and there are four chips. The five ports are labeled IO01234. So here what we see is that bit, let's see, 01234 of IO0 was set to one and yet we see bits three and four are received. So that's weird. And here is, let's see, the next case where we have IO1 bit six being set but nothing being received. Now, I think I can explain this failure. Here's a close-up of the chips and you could see how finely spaced these pins are with respect to my finger. Now, when I originally soldered these in, unfortunately, what I didn't notice is that I had some solder bridges between some of the pins. Now, on most of the pins, consecutive bits correspond to consecutive pins. So it is a little suspicious that the error that we saw was for consecutive bits. Now, here's the output stage of a typical pin on this GPIO expander. It's basically a MOSFET on the top and a MOSFET on the bottom. And that's basically all there is to it. So the idea is that if you want to send out a one, then this signal activates this transistor and this signal basically deactivates this transistor on the bottom. So that you get a path from positive to the output. And similarly, if you want to output a zero, you turn off the top transistor and you turn on the bottom transistor. And that allows current to flow that way. And that sends out a zero signal. With a solder bridge, what happens is this. We have two consecutive pins, each with their own driver. And unfortunately, their outputs are shorted. Now, what happens is when you activate one over here and you activate zero on the next pin, that forms a path between the high side transistor on one pin and the low side transistor on the other pin with no resistance in between. Now, these transistors have a maximum current capacity. And of course, just connecting them like this will definitely exceed that current capacity, which would result in damaging one or the other or both of these transistors. And of course, the same thing will happen when you output the next bit is that you will get a path from the high side transistor to the low side transistor. So it would seem that with a solder bridge running the tests would cause one or all of these transistors to be damaged. Now, here's the output again. And my theory as to what's happening is that we turn on the output. So we turn on the top transistor. Now, when we turn on the bottom transistor and turn off the top transistor of a damaged port, it's possible that this does not actually activate. So in fact, what's happening is that this transistor is deactivating, but it's damaged so that it continues to conduct for a little while longer. And if you've seen my series on MOSFETs, you'll know that the gate actually forms sort of a capacitor with the MOSFET. And in order to turn the MOSFET on, you basically have to put charge into the capacitor until the transistor turns on. In order to turn the transistor off, you have to drain that capacitor. And if you simply disconnect the gate and don't drain the capacitor, the transistor will remain on until the capacitor over here just sort of drains naturally. Now, these transistors are of course smaller being on a chip instead of being a discrete device. So the capacitance is gonna be a lot smaller. So it's not unreasonable to think that if this transistor is damaged or this wire is damaged or whatever, that this transistor will remain on until the capacitance here drains, which could be a fraction of a second later, which would appear like a stuck bit. So that's what I think might be happening. And this was all due to the fact that I had solder bridges between pins that I didn't notice and then I ran the test, thus damaging the chips. Now, of course, that's just a hypothesis. I have no idea if that's actually true. And it was a little disheartening to see the sheer number of solder bridges that I just didn't notice. So what I did was I put together a third tester and this time I checked every single pin to make sure that it was not connected to the next pin over. So there are guaranteed no solder bridges on this board. Now, I've taken the transmitting or output FT232H from the damage tester and put it onto here and no, this would not have been damaged because the only thing that this board does is speak I squared C to these chips and the I squared C bus is fine. I've also built, it kind of looks like a scoreboard. Really all it is is a board with a bunch of jumpers and LEDs on every signal on the backplane so that I can actually see the state of every signal. And if I wanna test the inputs of this board, I can actually jumper whatever signal I want. Now, I'm going to do this test by simply outputting one bit at a time and just watching the board to make sure that none of the bits get stuck. So let's see what happens. Okay, so here's the LED board. These lights are on just because they signify that power is being provided. And starting up the program now. Okay, and that was it. So of course, the last bit is on because we didn't bother clearing the rest of the bits. So this seems to be fine. Now, let's go and grab the bad board or what I hypothesize is the bad board and see if we can actually see anything. Okay, so I have put in the bad board or what I think is the bad board and I'm only testing U2 and I'm only testing port one because that was IO0, sorry, port zero because that was IO0 and that was the one that was displaying the problem. In addition, I'm having half a second per bit. So let's see what happens now. Okay, I didn't see the problem. Let me run it again. Okay, and again, I still do not see two LEDs going off at the same time. Now, this may very well be because just the load of the LED alone is enough to sort of drain that faulty transistor. That's another hypothesis. So now the next thing that I'm going to do is I'm going to take the good board, the one that I believe is perfect and test it against the input board that I was previously testing against to see maybe if the problem is with the input board. So here we go and I'm going to test it and looking for U2 specifically. Uh-huh, we got a failure. Okay, this time the failure is with bit seven of IO0 where we did not receive anything. So I do know that when I set bit seven of IO0 of U2 that I know that the LED goes off, turns on rather. So maybe the problem is with this input board in which case what I should probably do is make a totally new board and use that as the input board and make sure that there are no solder bridges that everything is perfect with it. All right, so I've gone ahead and put together a second board and tested it with the LED board and all the outputs seem to be functioning properly. This is the original good board. So now I have two good boards at least in theory and these are the hypothetical bad boards. So I'm going to set this up as the output, this up as the input and see if we can get all of the bits to work. And here we go again, testing outputs to inputs and U4 passes. So what I like to do is run this test a few more times just to make sure that there isn't some marginal output or input, okay? So I've tested that twice and it works fine. Now what I'm going to do is I'm going to swap the FT232 boards so that I swap outputs and inputs to make sure that the opposite direction is working. And there we go. All bits are working properly in both directions. So I now have two testers, which means that I can use them to test other boards, such as the ALU. And I've built the ALU. The only thing that I haven't done is program the flash ROM chips, which will flash the ALU RAM. And the other thing is that we've learned that it's extremely important on these chips to make sure that all pins are not soldered together. Solder bridges are very bad, especially when you've got two outputs that are soldered together. And when I put this board together, I was very sure to make certain that consecutive pins were not soldered together. And in fact, I will probably do a final pass through every single chip to make sure that none of the pins are soldered together because I don't want to damage this board. There are a lot of chips on here, even on the back. So hopefully next time I will have this ALU board programmed and then I hopefully will be able to use the tester to stimulate the ALU. And it looks like this episode turned into an episode of Rob Tries To Fix A Thing.