Verifying key functionality with small focused test programs, part 2

 VERIFYING THAT THE TOUCH PAD INTERRUPT WILL BE SEEN

I have wired the interrupt pin of the LCD + Touch module, which hosts the user interface of my product, to the LTC connector, pin 14. This should be routed to the GPIO1 bank of HPS I/O signals, at signal GPIO40.

Looking at signals on the GPIO1 bank is easy - provide addressability to a specific memory location that is mapped to this bank of signals and look at the bit associated with the signal. My code shows the bit value as I connect LTC pin 14 to 3.3V and to ground, ensuring that my code can see the interrupt when the user touches the screen.

I was previously unable to test this because the default logic loaded on the SD Card rerouted this signal to make it inaccessible from Linux. Now that I have set up my own logic with Linux running, I could test again. 

The initial results showed no change. I then checked the state of the pin I/O direction and forced it to be an input, but that was no better. I got suspicious and began to search through all the docs including the schematics, where I found that this pin is pulled up with a resistor and grounded as an output to switch the LTC connector between I2C and SPI signals. It is not a general I/O, just an output, I believe as the device drivers must be forcing this to a constant value such that I can't toggle the signal. 

Pullup on the HPS_LTC_GPIO pin

I had to pick a new pin where I could route that signal to detect that the touch pad interrupt was being generated because of a user interaction. I chose LTC connector pin 9, which was HPS_I2C1_SDAT connected to pin A21 and visible on GPIO51. When I ran the tests, I was able to see this pin both on and off as I moved a jumper around. Success!

VERIFYING THAT WE CAN COMMUNICATE OF THE FPGA/HPS BRIDGES

I have set up two of the bridges between the FPGA and HPS sides in order to communicate between the two. One bridge is used to send simple commands, such as switch the FPGA logic to drive emulation mode, and to return status of the commanded operations to my code running under Linux. The other bridge transfers four words at a time when loading or unloading a virtual disk cartridge image to the FPGA. 

This test program establishes addressability and then turns the drive emulation mode on and off, which is verified both by the status words being returned and by an LED which illuminates on the board whenever drive emulation is on. If one bridge works, I would expect the other to work as well. 

I did see the drive_ram signal activate when I issued the command - the assigned LED lit -- and the status coming back from my FPGA logic was normal. I however did not see the lamp go out when I issued the command to turn off drive_ram which I will investigate further. 

I did modify the test program to end by sending an Unload command to the FPGA which would start it looping reading data from the RAM buffer we set aside and making it available for reading from the Linux programs which would put the changed contents away on to the virtual cartridge file on the SD Card. 

I saw the drive_ram light go off and the Unload function LED illuminate. When I requested status over the bridge from the FPGA I received the correct value to indicate that a load/unload was in progress. I had made a temporary change to the FPGA logic which reset the command as soon as a status was read - this turned off the unload operation which is not what we want to happen, thus I will fix this. 

I rate this a success as I see correct operation of my logic to transfer commands and status between the FPGA and the Hard Processor System (HPS) sides of the chip, which is essential for my design to work properly.