Building cable to probe IOB6120, testing eBay 28F400 chip, testing Arduino flash loader device

THE CHALLENGE MONITORING SIGNALS WITH LOGIC ANALYZER

The IOB6120 board plugs onto the rear of the FP6120 front panel board using a 2x25 header plus a 2 pin connector. The male part of the header is on the bottom of the IOB6120 and the female header socket is on the back of the panel. Thus when they are plugged together the connector is hidden in the sandwich of the boards and can't be accessed.

Almost all the parts on the IOB6120 are surface mount and often with very fine pitch pins, making it almost impossible to clip probes onto pins to capture signals. The only practical way to monitor its operation is to capture the signals over the 50 pin header.

Since the male header is on the bottom of a board and plugs into a female below it, the handedness of the pins is reversed between the two headers. That is, pin 1 is in the upper left on one of the connectors and the upper right on the other connector.

This obviates using a simple cable method to probe the signals. If the chirality didn't change, I could have used an internal SCSI cable with three connectors, plugging one onto the FP6120, one onto the IOB6120, the using the third to attach lines to the logic analyzer. However, with the flip of signals, a signal on pin 1 is carried to the wrong pin of the other side. 

internal SCSI cable and breakout for logic analyzer connection

BUILDING THE CABLE

I bought some cables that allow me to cut apart and easily resolder the wires between a pair of 2x25 header connectors such that the pins flip and create true connections between the IOB6120 and FP6120. I carefully checked the new connections before installing this on the FP6120. I could then make use of the three connector internal SCSI cable to plug in the IOB6120 and attach logic analyzer leads.

Starting to flip the pins to cure the mirror image issue

Setup ready to hook to scsi cable and front panel

EBAY FLASH CHIP INSTALLED AND TESTED ON IOB BOARD

I found a seller claiming to have new unused Intel 28F400 chips for sale. They arrived a few days ago and I soldered one down on the IOB board. If it is real and works properly, then I can use the firmware of the SBC6120 to load the flash contents via the FL (flash load) command. This takes the text file on my PC and transfers it over the serial connection to the SBC6120 system.

When I first tested it, the SBC6120 hung during initialization, at the point where it issues a read to the flash chip on the IOB6120. This could be caused by defects in the board I built but more likely was a problem with the newly installed flash chip.

I pulled out the continuity tester and validated the connection between the flash chip pins and the far end of each such signal. This ensured that the solder joints are good and as well I tested for shorts to adjacent pins. I found that address pin A6 and the RD/BY# (ready, not busy) pins didn't have good connections. 

Even with that repaired, however, the startup of the SBC6120 hangs during the testing of memory, thus the board still isn't working properly. There are many things this could be including a fake flash chip, but I really can't proceed further without the logic analyzer capturing state during the startup. 

PUTTING TOGETHER MY ARDUINO SYSTEM TO LOAD 29F400 FLASH

Now that I have a pretty well tested set of Arduino sketches, at least offline on the Wokwi.com simulator, It is time to test with the actual chip. I installed the surface mount chip on an adapter whose DIP 48 pins were plugged into a breadboard. I wired up the 19 address lines, 4 control lines and 8 data lines to the Arduino Mega 2560, having flashed the first program which reads the contents of the 128K where I will store the ROM data. 

setup to load and verify flash chip outside of IOB board

I can monitor key signals with my oscilloscope to ensure proper timing and operation, thus I should be able to test the first of the three sketches to be sure I am able to talk to the chip. I chose the programming sketch, the one that accepts the text file lines over the USB serial link to the Arduino, parses them and writes the contents to flash, with a brief initial use of the verify sketch just to watch my control signals. 

More accurately, writing on a flash is called programming and all it does is set bits to 0 when its input is 0, but ignores 1 bit inputs. Thus, one has to first erase the sector, which sets all bits to xFF, after which you program it to flip the desired bits to 0 and leave the others at 1.

The verify sketch will set up the control lines appropriately and then assert addresses to the flash chip, let them stabilize, then lower CE# followed by OE#. That is held at least 35 ns. It enables the chip and turns the data lines to output. Sometime during the 35 ns the contents of the byte on the chip should appear on the data lines, get captured by my Arduino sketch, after which I drop the two control signals. 

The result, for a factory fresh chip, should be all 1 contents since the sectors are initially erased out of the box. The best I can do to check the chip and my setup is to run this to read out a word of flash which should show up as xFF. If the signals look correct, the minimum times for signal assertion are obeyed and the output looks good, I can move on to program some contents.

I will switch to the programming sketch, write a bit of the file to the flash chip and verify that ti seems to respond properly. Each write is a sequence of four cycles where I assert CE# and WE# sending specific patterns as well as the byte address and data to be written. At the end of the four cycles, the chiip should take some time to accomplish the write, signaling successful completion by raising the RD/BY# output signal. 

TESTING THE ARDUINO LOADER AND FLASH CHIP

When I hooked everything up and ran the first sketch to read byte 0, or any byte, I got xFF which is plausible. However, I then ran the code to program the chip, which seemingly worked correctly as the RD signal was asserted saying the write was complete, but the attempt to read returned the same xFF contents. 

I hooked up my oscilloscope as a first cut at diagnosis. I watched the RD/BY# line from the chip and tried to trigger on it going low - which is what should happen when the write is underway - but it never dropped. I then moved the probes over to the control signals to the chip to observe the waveforms and timing. I expected to see OE# stay high but CE# drop to low for a while with WE# dipping low inside that interval. I found that WE# was low at all times, which is not correct. 

My sketch should drop it for a short period, otherwise it would be high. I disconnected the wir from the flash chip to see what the Arduino is outputting but that still was low. This doesn't make sense. I verified that an Arduino would keep that pin high except for the dip during a write, which isn't happening here.

I need to dig deeper into this result to understand what is happening. If it is low all the time, it will definitely keep the chip from receiving the programming command (write) and should keep it from being read as well since OE and WE should never be asserted at the same time. I suppose I could even have a broken Arduino Mega 2560 board.