SPI link testing continues with some success; Wiring the Virtual/Real switch into the IBM 1130

DIAGNOSTIC INFORMATION I WILL WATCH

The SPI state machine moves through a number of states from the first to the 325th word being exchanged. To verify that it is reaching the end properly I emitted some signals that can be displayed on the scope alongside the end of transaction (SPItransaction going low). 

The state machine reaches a state SBcheckA when it has finished with the 321st data word and is preparing to send and receive the checksum of those data words. It then passes through SBtest where it verifies if an error free transaction has been received. Near the very end it reaches SBflagB state. 

I am also monitoring the command it believes it has received. One line goes high when it sees the bit pattern SCdrive that sets the RAM access to the drive side. Another line is the default state SCspi for when the RAM access should be connected to the SPI link. If an error condition is detected during the transaction, I would expect to see the command switch from SCspi to SCdrive for a while then revert before the end of the transaction. 

TESTING RESULTS AND OBSERVATIONS

I worked on various issues including not setting the command state to SCspi at power on reset, something that would have no impact on the system in real operation but needed repair to have a clean design. With the new instrumentation I discovered a small flaw, corrected it, and was pleased to see that the FPGA board switched the RAM over to drive mode from SPI mode - a successful transaction completion.

It appears however that something gets wedged after that one transaction, as I never latch in the subsequent command to switch back to SPI mode, while I can see the properly formatted transaction being received. I changed the diagnostic outputs and watched the state machine working well for the first transaction and it should be resetting to the idle state when the SPItransaction signal is dropped. 

Next up is a careful review of all the state machines and how they reset. It may be that I need to control how they move out of reset to avoid whatever is taking place to lock it up. I will also produce some new diagnostic output signals to help me find and resolve the issue causing this behavior. 

SWITCH BEING WIRED TO SWITCH DRIVE BETWEEN REAL AND VIRTUAL MODE

My modification to support the Virtual 2315 Cartridge Facility is a switch that reroutes signals that ran to the Head Load solenoid and the Heads Loaded microswitch. In the Real mode, signals are wired as usual, but in Virtual mode, the solenoid is out of the loop. 

For Virtual mode, the signal that would activate the solenoid is instead routed up to the Arduino inside my facility. The Heads Loaded signal line to the drive electronics is disconnected from the microswitch and instead routed to the Arduino. This lets the Arduino see that the drive electronics is requesting the heads to be down on the platter surface and the Arduino can lie to the electronics, telling it that the heads have indeed come down. 

I bought some final connectors and a mounting plate to install the switch in position on the frame of the IBM 1130 behind the disk drive. The remainder of the wiring and the physical installation will take place over the next few days. 

Head loading modification installed and tested

CONSTRUCTION AND INSTALLATION OF THE STOP ON HEAD LOADING MECHANISM

I bought a small bracket to install on the drive. It is needed to add a small fixed pre-movement of the load mechanism at all times, which will permit the arm to be moved in and out even when the heads are not loaded down on the disk. 

The solenoid that loads the heads down on the disk surface pulls a rod that pivots a structure and removes a wedge that holds the heads up high of the surface. The spring loaded structure lowers them down and keeps a fixed downward pressure as they fly. A bent lever on the structure contacts a microswitch when it has pivoted all the way to the point where the heads are down on the disk surface.

That bent lever moves to its full rest position when the solenoid is not activated, then is pulled to the other extreme as the pivoting structure loads heads. When in full rest position, the structure has a ridge that blocks the disk arm from moving out from its retracted "home" position. 

Since my scheme blocks the solenoid from activating, thus blocking the heads from lowering on to the disk surface, I want the arm to move freely without head contact. I discovered that a vary small amount of rotation of the pivoting structure clears the block on arm movement but does not begin to lower the heads at all. 

The bracket I bought was fastened on the mechanism to hold the bent lever slightly in from its rest position, enough so that the arm can move. It fits to the rear of the bracket holding the solenoid and microswitch, bent over to fit behind the bent tab which operates the microswitch. 

Top view

Side view

TESTING THE PRELOAD TO ALLOW ARM MOVEMENT

With the bracket in place, I tested the free movement of the arm assembly to position the heads to any of the 203 cylinder positions radially towards the center of the spindle. Everything checked out well. A future test will verify that with the switch installed and set to the Virtual 2315 position, we can get the drive to go Ready without the heads down on the disc surface. 

Arm fully forward past cylinder 203 position

Arm in its retracted Home position - cylinder 0

New SPI logic installed, testing the link again

OPEN SOURCE SPI LOGIC SUBSTITUTED

I had previously used a very well written set of SPI modules and decided to put that into my project. This was part of the SPI MASTER/SLAVE INTERFACE project http://opencores.org/project,spi_master_slave written by Jonny Doin (jdoin@opencores.org, jonnydoin@gmail.com) as described in the code. 

This operates differently from the code I first wrote, thus it forced some changes to the state machine that was driving the emission and reception of words coming over the SPI link. I successfully tested those on the simulator. 

LATCHING FIRST WORD TO DISPLAY VIA LEDS

As a way of further testing what is being received, I added in a register that is latched from the input at the time we receive the first word of the transaction. That was now visible on the four LEDs (in groups of four bits) as I set the slide switches to 0010, 0011, 0100 and 0101. I should see the left five bits showing the command code, either 10101 or 01010 depending on which of the two transactions has last been processed. 

RESULTS OF THE TEST RUN

The FPGA was latching the proper first words but the transactions were not completing. Keep in mind that I am using a scope to look at the transactions, triggering on either the start of the transaction or the end of it, using the SPItransaction signal. I was not looking at the entire 325 word transaction.

MOSI yellow, SS green and SPItransaction blue

That was the key to my first discovery. The code on the Arduino was only sending one word of data, instead the transaction was too short. I wouldn't have spotted this from the FPGA simulation since my testbench was what generated the traffic, not the Arduino. 

With that corrected, I was still not getting through to the end of the transaction successfully. I will need to instrument carefully to watch this both with a scope on diagnostic output pins and via the LEDs on the board. 

SPI link testing, designed interface PCB and sent to fab

INTERFACE PCB DESIGNED AND OFF TO FAB

The various parts of the Virtual 2315 Cartridge Facility operate at different voltage levels. IBM's SLT logic in the 1130 and its disk drive have a high of 3V. The FPGA operates on 3.3V signals and the Arduino Mega 2560 is a 5V device. Thus there are level shifters needed for signals moving between these devices. 

In addition, there needs to be a secure way of disconnecting and reconnecting the system to the IBM 1130 since ultimately the signals from the drive are accessed by wirewrap onto the backplane pins. I developed a board that will mount on the back of the disk drive, inside the covers of the 1130, which has two 40 pin IDE connectors on it. It is 5 3/8" wide by 2 3/4" high.

PCB

One IDE cable will be run to an IDC connector bolted to the side of the disk drive SLT card cage, with wires running to the points on the backplane where we access or drive the signals needed for the facility. The other cable will run to a connector on the box that contains the FPGA board, the Arduino board, an LCD screen, Pushbuttons, and the SD card socket. 

The only other part of the facility is a DPDT switch installed on the back of the drive that reroutes two signals from the drive. One is the signal from the electronics to load the heads, the other is a line that senses the state of the microswitch closed when the heads are down. This flips the drive between its normal (physical) mode and the virtual cartridge mode.

I have all the MOSFET transistors and resistors on order. The boards should arrive from the fab in about a week when I can solder it all up and test it out. 

SPI LINK TESTING

I used the scope to verify a number of the key link characteristics are correct:

• Clock period is 250ns for a 4MHz SPI link speed
• The clock is normally high when idle
• The bits are sampled on the rising edge of the clock
• Slave select bounds the exchange of an 8 bit byte on the link
• The bits are coming out on the SPI link in the order I expected

I set up a better testbench with more solid wire connections and good grounds between the FPGA, the Arduino and the scope. The FPGA is set up to show me the value received from the SPI link. All was ready to conduct the testing. 

I never got an error latch on the FPGA, thus it always passed the muster of having the second word be an exact inverse of the first word. Whether these are seen in the correct or the reverse order (bit 0 to 15 instead of bit 15 to 0) is not yet clear. 

The scope showed me the transaction ending with the good flag x5A5A but that will happen as long as we don't have the mismatch of the first two words. Again this suggests some degree of health in the link.

However, the two commands did not take effect. They should have toggled the FPGA between Ram to the drive and RAM to the SPI link, flipping one of the tricolor LEDs between green and blue. It stayed in whatever state I forced it to with the pushbuttons. 

Beginning of a transaction

End of transaction

For tomorrow I will be emitting some diagnostic data to help me debug the SPI code inside the FPGA. In parallel with that, I have begun to swap in a more powerful and well designed slave module I have used successfully in past projects. It requires a bit of redesign of the SPI handling logic but I believe this is worth substituting for the existing logic. 

Capacitor removed from Arduino and secondary SPI clock is clearly working properly

BUZZED OUT THE CAPACITOR THAT WAS SHORTING 4MHz CLOCK TO GROUND

I found the capacitor which had one end connected to the AREF external connector of the board. Given its relatively large capacitance, its impedance at the clock frequency of my SPI link was nearly zero. 

REMOVED FROM BOARD AND HOOKED TO SCOPE

It was quickly desoldered. The repaired board was taken to the bench and the scope connected to the AREF external connector pin which was now wired to the SPI clock for USART 2 on the microprocessor. If the clock was now working, with the scheme I put in place there should be bursts of 16 clock cycles every second or two while my Arduino looped around sending alternating commands to the FPGA.

CHECKED WITH THE LEVEL SHIFTERS TO PROVE THEY CAN HANDLE FREQUENCY

I also connected this through the level shifter boards I will be using, as I needed to be convinced that the shifters could operate with a 4MHz signal. The results were great! The clock from the SPI link clearly showed up on the scope in bursts of 8 cycles with the rest state high.

The voltage of the Arduino produced clock swung between +5 and 0V, while the output of the shifter moved in concert between +3.3 and 0V. The waveform was not distorted too much, a possible outcome if the shifter couldn't handle the 250ns cycle time and 125ns duration of the 'on' phase of the clock. All was good with the signal quality and levels. 

ONE ISSUE TO RESOLVE, OTHER THINGS TO VERIFY NEXT

What was evident immediately, however, was that I was NOT getting the 16 bits I expected during the SPI transaction. The ATMEL documentation made it sound like the buffered USART would accept two bytes and send out both in one transaction, but that is not what I am seeing on the scope in real life. This could be a C coding error or a misunderstanding of the documentation. 

In addition to that, there are several other things that must be verified to ensure that both ends are able to communicate. These include clock polarity, clock phase, and endian-ness of the transmission. I can change these at the Arduino to ensure a match with the FPGA but they must be verified and adjusted in necessary to have a good link. 

Polarity for an SPI clock is whether the idle state of the clock is high or low. I want high and that is what I see on the scope, so clock polarity passes muster. 

Clock Phase is a design choice for when signals are sampled - rising or falling edge of the clock - and as a consequence when they can be changed from one bit's value to the next. I can only verify this by watching the MOSI line, where the master (Arduino) sets up the 1 and 0 values of the bits in relation to the clock. 

The Arduino takes a parallel word input to the SPI channel and shifts out bits one by one. What we need to see is whether it should put the most significant or the least significant bit out first. The goal is to have the assembled word in the FPGA match what we expect, not be swapped back to front. Again I can observe this by watching what the SPI channel outputs on MOSI and SCLK from the pattern I am writing 

Of all the pins I could have chosen to repurpose for the secondary SPI channel clock . . .

AREF SIGNAL HAS A SNEAKY CAPACITOR TO GROUND I DIDN'T NOTICE

I discovered alternative schematic files for the Arduino Mega 2560 which conflict with the ones provided by the official site. In particular, the signal AREF which is show on the official diagram as connected solely to the connector block pin labeled AREF, in the alternatives I find a capacitor on that signal with the other end tied to ground. 

Not a good thing to have on a multi megahertz clock line. At 4 MHz this capacitor has an impedance of 0.4 ohms, essentially a dead short to the oscillator signal. Even if my setup of the secondary SPI channel on USART 2 is correct, I wouldn't have much of a clock signal available. 

REMOVING THE CAPACITOR FROM MY BOARD

Reworking to pull that capacitor off the board was quick and easy once I knew it had to be done. If by chance the USART clock was damaged by the short, I have three other USARTs I can switch over to on this board. 

First testing of SPI link between the Arduino and the FPGA - SPI is not trying

VOLTAGE LEVEL CONVERSION CIRCUITS BREADBOARDED

The FPGA input output pins are set to LVCMOS 3.3V logic levels, but the Atmel Mega 2560 processor operates with TTL 5V signal levels, thus I have to insert a level shifting circuit in the SPI link lines MOSI, MISO, SCK and Slave Select, as well as with the SPI transaction flag line. 

When I build the final production version of the Virtual 2315 Cartridge box I will have manufactured a printed circuit board to hold the level shifters, which also are needed for the thirteen lines between the IBM 1130 disk drive and my FPGA board. 

WIRED UP THE TWO BOARDS AND SET TWO STARTUP TRANSACTIONS

I tied the grounds of the two boards together and then snaked the signal lines through the level shifter breadboard. The Arduino code was modified to loop sending two initial commands over the SPI link, turning the RAM access over to drive mode and then switching it back to SPI mode. Success will be immediately visible on color LED 0 which will shift to blue when the board is in drive mode. 

OBSERVATIONS DURING THE FAILED COMMUNICATIONS

The clock of the SPI secondary channel never oscillated, nor did I see any action on the MOSI line. This tells me that the channel was not initialized properly or there is some other defect. I verified this on the TTL (+5V) side as well, it is not a level shifter failure.

LIKELY ISSUE IS SETUP OF THE SECONDARY SPI CHANNEL ON THE ARDUINO

I need to walk through all the documentation from Atmel on setting up the USART for SPI Master mode as something is definitely not right with my Arduino sketch.