2.8'' ILI9341 SPI LCD and XPT2046 Touch Controller

[ALomb]

I'm trying to integrate the display in question with TGX 4.13. This is the LCD module.

I developed the drivers for both display and touch, configured the project and trying to follow what is reported in the documentation at this link (spi scenarios for ST7789H2).

I have an error during compilation which is as follows:

../TouchGFX/target/TouchGFXHAL.cpp:91:8: error: 'class TouchGFXHAL' has no member named 'copyFrameBufferBlockToLCD'; did you mean 'setFrameBufferAllocator'?

How to solve?

[LVers.1]

Thanks Martin,

I think your proposed approach is indeed more efficient than just waiting for the DMA transfer to complete in flushFrameBuffer()

[Martin KJELDSEN]

Let me know how it works out for you :)

[LVers.1]

Hi Martin,

I'm pleased to confirm it works pretty well.

What i do is

1) have a flag that is set in sendFrameBuffer() (to indicate a dma transfer is ongoing)

2) wait till this flag is cleared on entry of sendFrameBuffer() (to make sure a second dma transfer won't be started before the current one finish)

3) using the HAL_SPI_TxCpltCallback() to subsequently transfer the next lines required by touchgfx (some static variable are used to keep trace of the current line and other relevant data)

4) clear the flag in HAL_SPI_TxCpltCallback() when there are no more lines to send

i'm printing out the lost frames counter and i definitely see an improvement on it. Which means the cpu is free to proceed further with some touchgfx rendering while a frame is transfered to the lcd.

One remark though:

At first i had a hard time to get the spi working with DMA.

Even something as simple as replacing a blocking call to HAL_SPI_Transmit() with a call to HAL_SPI_Transmit_DMA() followed by a blocking loop to wait the end of the transfer failed:

/* Send the pixels */
  //HAL_SPI_Transmit(&hspi2, (uint8_t*)p_buf, size, 100);
  HAL_SPI_Transmit_DMA(&hspi2, (uint8_t*)p_buf, size);
  while(hspi2.State != HAL_SPI_STATE_READY) {};

The spi remained in TX_BUSY state.

with the help of this post: https://community.st.com/s/question/0D50X0000AxEm8U/solved-spi-dma-doesnt-transmit-anything-is-my-configuration-wrong i called MX_DMA_Init() before MX_SPI2_Init(); and this fixed the issue.

It's a bit annoying to redo this change everytime i regenerate the code from STM32cubeMX so it would be nice if you could confirm 1) this is a bug in cubeMX 2) it will be soon fixed

Thanks,

Laurent

[Martin KJELDSEN]

Aha, that's unfortunate!

I don't have time to confirm, but you could add a call to MX_DMA_Init() inside a user code section that's before MX_SPI2_Init() ?

/Martin

[LVers.1]

well, that's exactly what i did for the time being and it works indeed, but you'll agree it's not the cleanest workaround :)

/* Configure the system clock */
  SystemClock_Config();
 
  /* USER CODE BEGIN SysInit */
 
  /* LVE: see https://community.st.com/s/question/0D50X0000AxEm8U/solved-spi-dma-doesnt-transmit-anything-is-my-configuration-wrong 
   * MX_DMA_Init(); must be called before MX_SPI2_Init(); so we place a call here to avoid to change everytime code is generated from STM32CubeMX
   */
  MX_DMA_Init();
  
  /* USER CODE END SysInit */
 
  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_CRC_Init();
  MX_TIM16_Init();
  MX_TIM2_Init();
  MX_I2C3_Init();
  MX_SPI2_Init();
  MX_DMA_Init();
  MX_TouchGFX_Init();
  /* USER CODE BEGIN 2 */

Regards,

Laurent

[Martin KJELDSEN]

I completely agree :) I or @Romain DIELEMAN​  will report this.