Debugging Tool: Bus Monitor
After the successful free running yesterday, my mind has been doing it’s own free running with all kinds of ideas. In particular, how I was going to test that memory is performing correctly. It will no longer be good enough to just observe the Address Bus with Hex Display, I need another debugging tool to see what is on the Data Bus as well. It would also be nice to be able to view a sequence of addresses and data, Hex Display has no memory.
Initial Proof Of Concept
Recently, I have been playing around with MCP23017’s on the Arduino so that I can have more I/O on another
project I am working on. The MCP23017 is a 16-bit Expander (2 * 8-bit ports) with an I2C interface. I thought this would be ideal to use with TLC-MBC. So as a first step I removed Hex Display and replaced it with a MCP23017 which connected to the Nano with just 2 wires to Analog pins 4 and 5 which double up as SCL and SDA for the I2C.
For a quick and dirty test, I used Adafruit’s 23017 library so that I could quickly adapt the previous free-running program to use the MCP23017. This time there were no led displays, instead I used the Serial Monitor in the Arduino IDE. Success!! The Serial Monitor was showing a stream of addresses. I’m on the way to having a new debugging tool. 😉
Formulating the Debugging Tool
With that success, I wanted to add the second MCP23017 so that I could monitor the Data Bus as well, but I did not exactly like the growing rat’s nest of jumpers. There’s going to be enough of those when I add the memory and I/O and I think these will just get in the way, not only that the two 28pin MCP23017’s are taking up space on the bread board. There’s only one thing I can do,and that is to put the chips on a stand off/header so that they sit above the processor.
To control specific devices on the I2C bus they are given individual addresses. On the MCP23017 this is made up of two parts. The first is hard-wired into bits 3 to 6 as 0100 in binary, the second is through bits 0 to 2 and these are brought out to pins on the chip so that you can set them high or low. For the first MCP23017, I tied bits 0-2 low so that the address is 00100000 = $20 or 32 in decimal. For the second MCP23017 I tied bit 0 high and the other two bits low so the address is 00100001 = $21 or 33 in decimal.
I’m using only Port A of the second MCP23017, I hate to waste half of such a useful chip… Why not connect Port B up to some of the 65C02’s control lines? I may not use them right now, but they may be useful to monitor when I have more chips on board and there are problems? Also, by default the MCP23017 ports are defined as inputs so they will not affect the control lines of the 65C02.
While I’m at it, as I’m bring the SCL/SDA lines from the Nano, I may as well bring the external clock signal, PB3, as well so there’s less clutter on the bread board. In conjunction with that I can have a header pin going down to the oscillator’s output to eliminate another jumper wire.
Finally, now there will be no jumpers tying the Data Bus to the value of $EA because it’s connected to the MCP23017. If I want to read the Data Bus I cannot write to it at the same time! To overcome this I’ve added an 8 position dip switch, with the input side of each switch being tied to ground through a 10K resistor and the other side tied to +5V. In the off position the value is low, when turned on it then high.
Now I just have to build and test my latest debugging tool, I’m going to lay it out in Eagle to make sure I haven’t missed anything and then prototype it on a piece of perfboard. Then I have to update the Nano driver program to read both MCP23017s. So, I’ll have some lunch and build it this afternoon and let you know the results.
Building and Testing
Took a bit longer than I expected, doesn’t it always?, but the debugging tool is finished. My main concern with
it was the clearance between the bottom of the board and the top of the bread board and components. I had some longish gold plated header pin strips, I pushed the plastic down to one end of the pins to maximize available length., and all wiring was done on top of the board. As it is there is about 6-7mm clearance. The jumper just above the cable is the clock “switch” and it is currently selecting the Nano as the source of the clock.
The eagle-eyed amongst you are probably thinking that the dip-switch has been set up wrong – it looks like $E9. Normally you would be right, but not this time. During testing I found that I screwed-up the connections for d0 and d1, and they are reversed. As this is a prototype, I shall leave them as is, as it’s quite awkward to desolder and swap positions.
Here it is installed on the bread board, hovering over the 65C02. It’s got it’s pros and cons. In it’s favor, Bus Monitor can capture all the info I need and it has made more space available on the bread board. It’s bad points – it has to be unplugged to add connections to other chips and there is only one hole available per pin of the 65C02. Schematics and program will be up on Git Hub this evening.
As I was writing the driver for it, it hit me just how useful this could be. At the moment I am reading the state of all the pins, the MCP23017 ports are all inputs. But what if I made them outputs? Say for example I have a board that has a hardware problem, I could unplug the processor and plug Bus Monitor in it’s place and then use it to debug connections etc. A not-so-Static Processor Emulator. So as a debugging tool, Bus Monitor might be more useful than I originally planned, I just have to write the driving software for it.