Drawing on the LCD screen to test functions I need - part 4

SCOPE REVIEW OF SIGNAL CORRECTNESS

There was a bit of delay working out how to get the scope probes on the jumpers, since both connectors where the jumpers plug in are tightly spaced. Plugging in my 2x7 cable for .5mm pins at 2mm spacing, I yanked the other connector off and gained access to the wire ends. 

Pin 4 is the SPI clock signal, pin 7 is the SPI MOSI signal and pin 5 accepts the SPI MISO signal. SPI Slave Select sits on pin 6 and will be useful for triggering although the actual slave select going to the LCD module comes from the FPGA side GPIO pins and not the SPI modules slave select logic. I had to do this to deal with the kludge protocol required to drive this LCD Module. 

I saw no signal activity at all. Nothing. The SPI module is not working or not being routed as it should out through the LTC pins. My program was supposedly looping writing command bytes to the module which should have toggled slave select, drove the clock, and output the bit pattern I wrote. 

DEBUGGING STEPS

My first thought was that it was the damnable poorly documented routing mechanisms for the Cyclone V and the Quartus toolchain. I went back to the tool and opened the pin planner. To my surprise, I found that the SPI signals were NOT connected to the Cyclone V chip in spite of the Platform Designer and Quartus statements directing this to happen.

I look at the table and noticed that the pins listed for the SPI master in pin planner were different from the table in the user manual. I then opened my master spreadsheet of all the signals and routing for the Cyclone V chip to dig into it. To my surprise, I discovered that the SPI master connected to the LTC connector was not SPIM0 as I expected and configured - the primary SPI controller - but SPIM1 a second controller. 

As you can see, neither the table nor the diagram that sits above it has bothered to distinguish which of the two SPI masters is involved. The signal name HPS_SPIM_MOSI is not a real signal name, there are instead HPS_SPIM0_MOSI and HPS_SPIM1_MOSI and had some lazy so and so bothered to type the number I would have saved quite a bit of time digging into this. 

This is why I had some activity when my earlier design had routed the SPIM0 signals out to the FPGA and to GPIO pins. That method required me to introduce IO Buffer blocks which introduced delays in the signals, which was the impetus for me to switch over to the LTC connections instead.

I can change routing to get the SPIM1 routed to the LTC pins, replacing SPIM0. I would also need to change the offset I use to access the SPI control registers in memory, as SPIM1 is mapped to a different range of addresses. 

The remaining potential issue is that there is a Linux driver enabled for SPIM1 according to the device tree blob file. I used the dtc compiler to access this, vi to change spim1 to disabled, the compiler to format as a blob and was able get Linux to boot properly.

RESULTS OF SWITCH TO THE SPIM1 CONTROLLER

Still no signals showing up on the oscilloscope while the program is looping writing to the SPI channel. I realize that the device tree had listed a specific peripheral using SPI as attached to SPIM1 which may cause the driver to still interfere. My next change will be removal of this device mention in the device tree. 

For diagnosis, I began to litter the code with diagnostic printf statements so that I can validate every address being used. I also accessed and displayed lots of values to demonstrate that I have done what I expected to accomplish.