Still can't get an answer back from the touch controller chip

TRYING TO COMMUNICATE WITH THE TOUCH CONTROLLER CHIP

I carefully compared my code communicating to the touch controller with what was working properly talking to the LCD controller. I looked for flaws, I checked that I had the correct pin assignments inside the FPGA. I even slowed down the SPI link further to just over 1.5MHz in case there was a problem with the higher speed. 

There are varied claims by the vendors of the LCD Module, its documentation and even in the sample library from Waveshare they distributed. Right where it does the access for the touch controller, however, it is setting the SPI link to 3MHz for those communications and then back to 18MHz for transmissions to the LCD controller. Just in case the timing is critical I will again change the slow speed of my SPI to a 3+MHz. 

Putting the oscilloscope on the SCLK, MOSI, MISO and pseudo SS (Touch Select) wires let me watch what we sent to the touch controller and what came back. That can be compared to the timing diagram from the XPT2046 data sheet. 

The MISO line, the output from the XPT2046, never budged from 0. I sent a different command asking the controller to send me the value of the temperature in the chip, but it also returned 0. I could see the Touch Select (chip select) go low for my transaction, the clock enter the board and the MOSI line send the command byte plus two bytes of 0 as required to get back an answer. 

I switched LCD Modules, same result. I disconnected the MISO line from the FPGA to eliminate the chance that the FPGA is dragging down the line. Still nothing coming out other than continual zeroes. 

I have to believe that this is a timing issue of some sort, where the touch controller chip is not triggered properly to deliver output on the MISO line. I started looking at the original sample code before I had ported it, since this may be a porting error on my part. I see that the code does a pause of 200 microseconds between the first byte transmitted (command word) and the next two bytes of 0 which allow the chip to send back the measurement. 

The way this is implemented is through a highly unportable, crude method of running in a loop 200 times to burn off the amount of time that a Raspberry Pi Pico would consume. I dropped it to 1 microsecond but that is clearly too long if you look at the scope trace. 

Eventually I removed the delay and pursued all three bytes by pushing them into the FIFO, waiting until the last one was complete and then pulling three bytes out of the receive FIFO. No change although my scope trace looks very much like the amateurish timing diagram in the data sheet - I say this because there are no durations listed and instead it is kind of a representational picture not drawn to any scale, ergo pretty useless for engineering against. 

My last stab was slowing this way, way down to 125KHz SPI rate, hoping that if it is slow enough I should see MISO modulating with captured values. I did not. At this point I just don't understand what must be done to drive that darned touch controller to return a non-zero output. 

As a complete fallback, I could install three physical buttons for the up, down and select operations, ignore the touch functionality entirely, and complete my user interface. That might not be the worst thing to do since I still don't know what accuracy and repeatability, if any, I can expect from the resistive touch panel. 

I haven't totally given up yet but this is quite perplexing. I see the signals going in on the wires just as they should, matching the requirements as described in the datasheet, but nothing is happening. It acts as if it is dead. Two different LCD Modules act the same.