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

PAPER VERIFICATION OF CIRCUIT UNDER DIFFERENT SPI MODES

The four modes vary based on two factors - the idle level of the clock signal (CPOL) and the phase of the clock at which the incoming bits are latched (CPHA). The rising edge of a clock is when it transitions from its idle level to the opposite logic state, and the phase means whether the latching is rising or falling edge of the clock. 

When I look at the datasheet for the XPT2046 controller chip for the touch screen, it clearly shows the clock idle at 0 level and the the signals latched at the rising edge of that clock. This should be mode 0, with CPOL 0 and CPHA 0. 

The diagram for the LCD module has some 7400 series ICs cobbled together to drive a 16 bit parallel LCD controller chip, such that it would work connected to an SPI master.

The chip on the right is an inverter, although the labeling of the pins is not consistent with the chip. Pin 1 on the top left is the input and pin 2 is the inverted output for a 7404 hex inverter chip type. 

The chip on the left is a counter which is reset whenever chip select is high - that is whenever slave select is not asserted - then it counts on the rising edge of the clock input. Bit Q3 is the output - this goes high when the counter gets up to 8 and then stays high until we wrap around to 16 when it drops again.

The middle two chips are 8 bit Serial In Parallel Output shift registers that will accept the state of pin 2, MOSI, at each rising edge of the clock SCLK. Thus it is shifting in the incoming values at every CPHA 0 of polarity CPOL 0. The strobe pin 1 transfers the state of the shift register bits to output latches when it is high then the latch holds its value all the time that strobe is low.

The effect of the counter as the strobe input is that shifting of input data is invisible on the parallel output pins until transferred by having strobe high. As we count up from the start of a string of incoming clock and input pulses, pushing them into the shift register, we get the current value visible in the output latches once the strobe goes high, with those values changing with each additional input clock cycle until strobe goes back low. At that time we have frozen the value of the 8 bits even if additional MOSI bits are coming in. 

The serial output of the final bit of one chip is fed into the second chip as its data (in place of MOSI). This the two together form a 16 bit SIPO shift register, with the latched outputs appearing right after eight bits were shifted in and continuing to update until we have reached 16 bits. This supports the odd behavior of this module where we can send 8 bit, 16 bit or n*16 bit messages. 

At the end of 8 bits shifted into the first register, the strobe coming from the counter chip makes the contents available on the parallel outputs. If the chip select (slave select) is turned off then the counter is reset, the clock stops cycling and LCD module takes a look at the incoming parallel data. 

From the 8th to the 16th bit shifting in, parallel outputs show the current shifted value of the register, but at the 16th count it is frozen by the strobe going low again. When chip select is turned off after 16 bits, the LCD module looks at the 16 parallel values and processes it accordingly.

If we have shifted in 16 bits but don't turn off chip select, instead continuing to cycle the clock and deliver additional bits on MOSI, then the pair of shift registers hold the value of the first 16 bit word in spite of new data cycling in on clock counts 17 up to 23. At count 24 up to 32 the parallel outputs are changing as the data shifts in but again are frozen when strobe goes low at 32 ( and all subsequent multiples of 16 clock cycles).

The inverter on the right means that the LCD Clock signal is high whenever we have a locked in frozen set of parallel output values, either 8, 16 or any of the multiple 16 bit words. The LCD controller chip sees this LCD Clock as well as the chip select (slave select).

The ILI9488 LCD controller chip supports many interface methods but we have hard wired the mode pins to select the DBI Type B 16 bit interface. This is a parallel 16 bit interface with a chip select, a write strobe, a reset, a data/command and LED turnon signals in addition to the 16 data ones. The controller chip supports reads with various commands that will send back data, but that requires a read strobe pin that is not connected nor is the data out connected to the SPI MISO line. 

This confused me for a while since the code issues a read command to determine whether it is this 3.5" LCD module or a smaller 2.8" that is supported by the same library of code. The code determines it is the 3.5" module because the data returned is x00 but of course that is what you would see if the MISO line were not connected as is the case here. The 2.8" module must implement MISO and the read strobe pins. 

This foils one of my three tests for communications, where I believed I could issue a command that would read some manufacture identification information and send it back over SPI, but without the wiring I will always get zero. I will have to figure out the most minimum set of commands I can send to cause some detectible behavior on the screen. 

All of the above investigation makes me very comfortable that I have correctly identified this as mode 0, that is CPOL 0 and CPHA 0. What is a bit harder to determine is the bit order of transmission. We know that a command is just 8 bits with a (premature) termination via chip select (slave select) deactivation at that time. Thus the command bits were shifted in so that the high bit as defined in the data sheet is the last one shifted in. For a command such as xB0, we would see MOSI sending bits 0, 0, 0 0, 1, 1, 0, 1 on the MOSI wire. 

I write a xB0 into the 8 bit data register of the SPI master, with bit 0 on the right so that bit 7 is 1, continuing down to bit 0 having a 0, just as the contents will be in the shift register first chip upon completion of the transmission. What I don't know yet is how the Cyclone V SPI hardware shifts out that data. If it sends bit 0 first then we are in sync, but if it first sends out bit 7 on MOSI then my bits are flipped back to front. I suspect that it is sending 7 out first, since the SPI protocol mentions sending the most significant bit first and that would be bit 7. 

Some quick code inserted to flip all the bits didn't produce any better result that before. I think it is time to verify the basic signals are hooked up properly and behaving right - thinks like slave select and MOSI, reset and command/data mode.