-4

In one of my projects I use the cheap 2.4" 320x240 TFT display with a ILI9340/41 controller. It works quite good, taking into consideration the price, and I do not have any problems when I display something. But I can’t read anything. I think that it uses 4 wire SPI

Photo of connector

Datasheet

But unfortunately any read attempt is unsuccessful. On the first dummy write, I see some strange activity on the MISO line and MISO is driven high.

Waveform capture

void LCD_SendCommand(SPI_TypeDef * volatile SPIx, int command)
{
    ReSetBit(CS_PORT,CS);
    ReSetBit(DC_PORT,DC);
    while(!(SPIx -> SR & SPI_SR_TXE));
        *(volatile uint8_t *)&SPIx -> DR = (uint8_t)command;
    while(!(SPIx -> SR & SPI_SR_TXE));
    while(SPIx -> SR & SPI_SR_BSY);
    SetBit(CS_PORT,CS);

}

void LCD_SendPar(SPI_TypeDef * volatile SPIx, int par)
{
    ReSetBit(CS_PORT,CS);
    SetBit(DC_PORT,DC);
    *(volatile uint8_t *)&(SPIx -> DR) = (uint8_t)(par);
    while(!(SPIx -> SR & SPI_SR_TXE));
    while(SPIx -> SR & SPI_SR_BSY);
    SetBit(CS_PORT,CS);
}

Maybe someone knows where the problem is. I have tried literally everything.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
0___________
  • 60,014
  • 4
  • 34
  • 74

2 Answers2

2

From your code it looks like you only ever send one byte and then de-assert CS again. I suspect that's where you run into trouble.

Page 35 of the datasheet says that CS can be deasserted between command and parameter for write cycles. Read cycles don't explicitly allow it. Page 38 of the datasheet shows read cycles without deasserting CS in-between.

Also notice that for reads other than 8-bit a dummy clock cycle is needed. This might mean you need to manually generate the dummy clock cycle as the stm32 family in general only has 8-bit and 16-bit SPI communication. Maybe you can cheat and just read 3/4 bytes and lose the last bit and have the value shifted by one bit. Another idea might be to use a USART and switch between 8-bit and 9-bit synchronous modes. You'd have to adjust the Endianness of commands/data then, though.

FRob
  • 3,883
  • 2
  • 27
  • 40
  • Or use a GPIO as CS, assert separately from the spi peripheral, then can do as many 8 or 16 bit cycles as desired. – old_timer Jun 07 '17 at 08:16
  • I have tried it as well. Same output. @old_timer I use GPIO as CS. Everything works as a charm except reading example: [link](https://youtu.be/y4oxth7I1l0). Before asking here I have tried all possible options except the 3 wire one. – 0___________ Jun 07 '17 at 08:44
  • 2
    generally reading from these kinds of display controllers is not needed for any reason, just trying to display pixels, a lot of write only stuff and thats it, so you have to ask yourself why do I want to read from it. second no reason to assume that the peripheral conforms to a spi standard (or i2c, etc) but hope that it conforms to its own datasheet although that isnt always safe, and for a device that the general population never reads from, maybe it simply doesnt work. – old_timer Jun 07 '17 at 08:47
  • @FRob - of course I do dummy writes to read from SPI. You can see them on the picture. But the MISO line is dead (almost). – 0___________ Jun 07 '17 at 08:49
  • 1
    if you actually tried all the possible combinations (I have tried literally everything) then there was no reason whatsoever to ask a question at this site, it simply does not work. why did you ask? – old_timer Jun 07 '17 at 08:49
  • I hoped that someone maybe had a bit more luck with it. Those displays are quite popular. The reason of reading is: identification of the display controller. – 0___________ Jun 07 '17 at 08:51
  • 1
    if you didnt literally try everything then why did you say you had, please edit your question? Since you only tried some things then why didnt you post the things you had tried? Are you trying to figure out how to use the spi perpheral in software to get it to produce certain waveforms (independent of the slave) or are you trying to get the device to respond in a certain way? The former is stackoverflow-ish (and the slave is only slightly interesting but possibly not relevant), the latter is completely not SO and belongs in the EE stackexchange, you may have better luck there. – old_timer Jun 07 '17 at 08:58
  • @PeterJ from your screen it's clear that you don't produce a dummy clock cycle and only perform full 8-bit dummy reads. Secondly, it's not clear if CS stays asserted between your reads or not. If the read code is anything like you have shown, then it's not and that's wrong according to the datasheet. – FRob Jun 07 '17 at 12:53
  • It was only one of the screens. – 0___________ Jun 07 '17 at 14:15
  • @PeterJ What do you mean? There are screenshots that show the dummy clock cycle? Then post them and show us what you tried! Also, label your signals, please! – FRob Jun 07 '17 at 15:42
  • @FRob Unfortunately I have deleted them already as the problem has been solved. – 0___________ Jun 07 '17 at 16:19
1

I have sorted it out eventually :). For some reason it requires two consecutive software reset commands to start sending data back :), and now it works as expected.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
0___________
  • 60,014
  • 4
  • 34
  • 74