Verifying key functionality with small focused test programs, part 1

SMALL PROGRAMS TO VERIFY THAT KEY ELEMENTS WILL WORK PROPERLY

Before I launch into full scale tests of the operation of the Virtual 2315 Cartridge Facility I have identified certain signals that must be properly received by my software in order to achieve the behavior we designed into the product. 

I set up small programs that minimally test these elements, allowing me to verify that I understand things correctly and have everything properly configured so that I can detect the signals as I expect. These were generated on my laptop and moved onto the SD Card of the Hard Processor System (HPS) on the board where Linux will run. I can log into the Linux system by a serial connection and execute the test programs to check off each test. 

VERIFYING THAT THE POWER GOOD/FAIL SIGNAL WILL BE READ

The power input monitoring signal is driven to ground when the supply from the IBM 1130 is active, but when power drops or the CPU itself drops, my product will be powered by a 12V battery to allow for a few minutes to properly execute a shutdown of the Linux image running on the board. This dramatically reduces the risk that the file system will be corrupted if there are writes on the fly when power drops. 

I tack a wire from my power monitoring wire to the HPS_USER_KEY pushbutton on the DE10-Nano board. This causes the pushbutton to appear depressed when my wire is pulled down to ground (good power) and it reverts to unpressed state if power has failed or is not present. 

This program allows me to test by simply pressing and releasing the pushbutton, as it is very unlikely that my tacked on wire will fail to operate properly. I have reviewed the schematic for the button and its traces on the board to ensure that I am indeed connected to the proper contact of the button. The action of the button is to connect my chosen contact to the other contact which is tied to ground.

My test worked properly, assuring me that my understanding of how to check signal values from the memory mapped areas is solid. This signal was available even with the provided Linux, system on chip design and FPGA logic for the board. Until I can load my own FPGA logic, the remaining signals pass through my logic or are rerouted in the default logic shipped with the board such that I can't access them. 

LOADING THE FPGA LOGIC AND BOOTING LINUX

The startup process for the board is:

1. Hardware functions execute the preloader
2. Preloader will load the U-Boot program
3. U-Boot takes actions including loading the FPGA logic into the hardware
4. U-Boot transfers control to the Linux kernel
5. Linux kernel and startup routines bring up the system to the point a user can log in

The U-Boot code is writing a fixed file name over into the FPGA but also invoking a program to configure the HDMI video link over in the FPGA to give a graphical interface through a monitor. The logic in the FPGA that handles the HDMI connection and video operations is intellectual property which is only available on the existing SD Card images, not to move into my own FPGA design. Thus, I can't use the HDMI link to support a graphical Linux desktop when my FPGA logic is loaded.

Some documentation from Terasic, Intel and on RocketBoard.org suggests that if the FPGA configuration file is not present, the Linux system will boot up without loading the FPGA. This would have allowed me to install my logic separately into the FPGA and then let Linux boot up. 

CAN'T GET ANY OF THE PROVIDED SD CARD IMAGES TO BOOT AND USE MY LOGIC

The existing SD Card images provided with the DE10-Nano load their own FPGA logic and configure signals between the FPGA and Hard Processor System (HPS) side where Linux will run. The existing code will NOT come up into Linux with my own FPGA configuration. It appears the documentation is out of date or was incorrect. 

The Linux kernel is apparently trying to communicate the the FPGA side HDMI logic very early in its startup, since it freezes if I replace the default file on the SD Card with my own FPGA logic. If I remove the FPGA file entirely, the U-Boot loader won't even attempt to start the Linux kernel. 

COULDN'T VERIFY 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.

The default logic on the SD Cards reroutes the signal from the LTC connector so that it is not connected to the GPIO1 bank. I have not means of viewing the signal state until I can get my own design into the FPGA which leaves this signal on GPIO1.