For a couple of days now I have been trying to get some visuals on a ILI9341 LCD screen.
I'm working on a STM32F723E-DISCOVERY board. The LDC screen works with an 8080 controller. According to the manual of the device the internal IM bits define wether it works in 3 wire or 4 wire serial mode, where 3 wire mode stands for CSX, SCK and MOSI/SDA. 4 wire mode stands for CSX, DCX, SCK and MOSI/SDA.
3 wire expects 9 bits where the most significant stand's for either D(data) or C(command). The instructions sent to the device are 1 byte each. 4 wire, the one that I suppose I am using sends a byte at a time and uses the DCX line to make the difference between data and commands being sent. DCX low means send command, DCX high means sent data (either command parameter or rgb pixel data)
Besides that, it also describes a difference between serial I and serial II, where serial I uses one line, MOSI/SDA for reading and writing and serial II, where reading and writing goes over MOSI/SDO and MISO/SDI. On different forums about arduino, raspberry etc, I've seen footage of both different configurations set up and running. First I attempted with Serial I reading and writing over one line, but this kept resulting in FTLVL full and nothing seemed to be transmitted to the LCD device.
Then I changed my code to be conformant to serial II and after some attempts debugging I discovered weird unexplainable data comming in on the RX fifo. After sevaral days of trying many different SPI and GPIO configurations, checking all the manuals into the finest details and keeping on trying, I found seemingly nothing got to work on the SPI.
The garbage data was sort of a relief, because it proves there is signal on MISO/SDI. I wrote an interrupt handler to see what was coming in but sad enough only zeros were read from the line and the transmission stopt after setting CSX low. But.. sending data to the device didn't cause FTLVL to overrun anymore.
I swapped two lines of code in my sources, so now CSX goes high first and enable the SPI later. This caused the stream of zeros to stop. All the screen initialization and byte data that's being send by my code still ends up no where and besides the backlight being lit there's still nothing shown on the screen. Not even the flickery grey stated after hardware reset, described by other people on different hardware platforms.
But, what does happen, during initialization, nothing happens on the Rx fifo. After sending a command, 0x09 (read display status), BSY stays 0, TXE stays one but, the screen seems to reply because I receive data on MOSI, as I can see in the debugger. FRLVL increases right after sending the instruction to the device, what means to me that there is some sort of communication going on and I receive an answer that must be triggered by the instruction.
But, once again, I receive only zero's and nothing but zero's. Besides that. If I debug on further through the code, I enter the function that contains the sending of the initialization instructions for the screen and I get data returned on the RX fifo for about every command I've sent. Not only that, I'm not reading from the fifo, but still, single stepping on trough the code where over lines over instructions where there is nothing being sent to or read from SPI->DR, still shows my FRLVL decreasing, from 3 to 2, from 2 to 1 and from 1 to 0, every single step I move on.
This makes my doubt the proper functioning of my SPI. I don't have a logic analyser, not yet, so besides what I see in the debugger I can't tell much about the output on the SPI. But still, I've checked my code and my wiring so thoroughly that I'm absolutely sure it must be right and still I get these weird results. Sending data or commands do result in response, otherwise the FRLVL would not increase right after transmitting any byte to the device.
What just does not make sense to me is the fact that I only seem to get '\0' in my char array that's being filled reading in SPI->DR and that the FRLVL Fifo threshold level decreases every single step I debug in the code when there is no read performed on SPI->DR.
Is anyone familiar with this particular issue? Is this a common thing with SPI or should I concider my device as not working properly, because that's realy what it starts to seem like. I realy hope anyone can tell me anything usefull on this, because I tried about anything possible and it seems like I'm running out of options.
