Still unable to 'touch' the touch controller chip

CLUE BURIED IN THE DATA SHEET

I found a tiny footnote in the datasheet under a graph that showed the variation in sampling rates due to factors such as temperature, but with small variation around 100,000 to 125,000 per second. The footnote had some cryptic formula that showed fSampling (125K/s) * f16 = f2M which I believe tells us that when this performs 125,000 samples per second producing 16 bit output from the Analog to Digital Converter (ADC) it would be clocked at 2MHz. 

I suspect that the ADC uses small capacitances to retain the voltage while it achieves the digitization during the 16 clock cycles. If it is run too fast, it can't produce a result. If it is run much too slow the sampled value bleeds away before operation. For this Goldilocks chip, the frequency must be 'just right'.

I imagine this can be clocked as slow as 1.6MHz to accommodate the low end of the sampling performance which necessarily must be supported by enough hold time in the ADC to still produce results. That is the frequency I planned for using the divisor 0x007C (124) to generate 1.613MHz for SPI from the 200MHz master clock. 

In reality the chip does not support a full 100K to 125K samples per second because it has the additional 8 bits of the command byte that has to arrive before the 16 bits of data output will be produced. Thus the 10 microseconds it takes at 1.6ish MHz also has a 5 microsecond period for the command byte. Thus the max rate we can request sampling is somewhere over 66,000 times per second and each sampling SPI transaction takes 15 microseconds. 

TEST SEQUENCE TO WATCH FOR MISO RESULTS COMING BACK

I set up a tight loop issuing sample commands for the temperature inside the chip, the command value being 0x84. This asks for a single ended voltage measurement across the temperature sensitive junction, at high resolution of 12 bit values (that come in the 16 bits returned along with four bits of 0 padding), allowing the chip to power down after each sample and to emit touch interrupt pulses as the screen is touched. Since the chip can 'instantly' power back up, this is the normal mode for a continuous stream of sampling. 

Nothing came back but zero bits. The same result I get with reading the X or Y coordinates. Is this chip working at all? I need to purely look at what is going in and out of the touch controller chip. 

SETUP TO WATCH THE FULL SPI TRACE

I wanted to use my four channel scope to see SCLK, MOSI, MISO and the software generated SS at the same time. I made that happen, with the MISO line removed from the FPGA and directly hooked to the scope so that I could see what it was doing without any interference.

As soon as I assert the SS line but dropping it to zero, I see the MISO line drop from logic high to logic low where it stays throughout the entire transaction. 

I measured the SCLK signal and verified it is at the 1.6MHz rate needed to talk to the controller chip. The signals were nice and clean within the constraints of my test setup. I saw three bursts of eight clocks that represent the three bytes being exchanged with the touch controller. 

I monitored the MOSI line and verified that it was transmitting what I intended. The first byte was 0b10000100 which asks for the temperature as a single ended measurement returning a 12 bit quantity. 

I verified that the clock is low when idle (sclk of 0) and that the incoming data on MOSI is held steady to latch it on the rising edge of the clock (spha of 0). The mode is what I intended and matches the diagram in the data sheet. 

Unfortunately, regardless of what command is transmitted, the response is always zeroes. 

Here is the oscilloscope trace of a transaction, with DCLK(SCLK) in yellow, DIN(MOSI) in green and DOUT(MISO) in purple. 

CS (Touch Select) isn't shown on the screen but when I enable the blue trace for it, I verify it goes low right when MISO drops to low. I removed it to have less clutter on the screen. The only difference with the representational chart they provided is that the time between the 8th clock of the first byte and the 1st clock of the second byte is wider than one clock interval. The chart seems to have that spaced wider as well, but with no numbers or other specifications I have no idea whether this is significant. 

PERHAPS I SHOULD SET UP AN ARDUINO TO DRIVE THE TOUCH CONTROLLER

I think I may grab an Arduino from my shop, wire it up and program it to drive the touch controller with commands like temperature sample or X position sample. I can then vary parameters until I can get the darned thing to behave as it should.