Reassigning signals to pins on LTC connector and verifying they can be used - and they cannot

HAD TO REASSIGN SOME SIGNALS

My recent discovery during testing that the slave select lines from the SPI master are not activated when I switch on the bit, but only during the time the master is transferring the contents of the transmit buffer once I wrote something. 

I was using select signals 3 and 4 to control the LCD Module's reset and command/data inputs, which will not work correctly. It is time to reorganize my use of the pins for some signals, so I undertook that task first, once I decided which physical pins are available for the connections. 

SIGNALS ON THE LTC CONNECTOR ACCESSIBLE AS GPIO FROM HPS

It appears from the documentation that I should be able to access at least 6 of the pins on the 2x7 LTC connector of the board, accessing them by their GPIOxx signal numbers. I had previously failed to access the seventh pin, HPS_LTC_GPIO, so there is some doubt that must be resolved by testing.

SELECTING WHICH TO USE FOR EACH SIGNAL

The six signals are divided across GPIO banks - that is, sets of 28 signals that share a single word in the memory mapped space. Two of them sit in bank 1 (GPIO1) and the other four are in GPIO2 (bank 2). When the user interface is active, it will be driving two outputs and watching two inputs for state change. I put these together in GPIO2 bank. 

 One input is the -pick signal which will tell us if the drive is switched off (heads unloaded), while the other informs us when the user has touched the surface of the LCD screen to select one of the three buttons. The outputs reset the LCD screen or inform it whether an SPI transfer is a command or data. 

The remaining two signals are an input, letting us know that power from the IBM 1130 is good, while the other is an LED we can light to signal some state of the system. I have not yet selected a condition to display with the LED. These two will be in GPIO1 bank.

TESTING REGIME

I modified my small focused test program to watch the various signals that I believed I could access from Linux programs. Some were inputs and other outputs. First I will verify that I can see the digital value of the input pins I selected. When that is working I can jumper one of the inputs to each output pin in turn, sending out the chosen value on the output and watching to see that value appears on the jumpered input. 

I had to double check that all my pointers made sense before I set the input or output mode of each pin and began my testing. The print statements to the console had the hex addresses and from that I could see that pointer arithmetic worked as I intended. For example, if one pointer is defined for 8 bit integers and another for 32 bit integers, with a value of x1000, adding 4 to the first gives an address of x1004 but the second one becomes x1010. 

All my pointers and the arithmetic on them worked perfectly. I also verified that the data direction registers showed that the GPIOs in question were all inputs. 

Next I tried testing them both with a jumper to ground and high. I did find three pins on the LTC connector that produced changes in the GPIO signals. One pin make GPIO51 go low, another made GPIO52 go low and a third caused BOTH 51 and 52 to go low simultaneously. Further, these signals are associated with the SPI master than I will be using from the FPGA side, so I am concerned that manipulating them through LTC will interfere with SPI operations.

Drat! Off to find another way to route the five signals I need to see or control from the Linux side.