cancel
Showing results for 
Search instead for 
Did you mean: 

Issues with LTDC and Audio Configuration on STM32 - Conflict Between Display and FATFS/Audio Playback (STM32F469i-DISCO

DerFreaker
Associate III

Hi everyone,

I'm encountering a problem with my STM32 project where I need to use both LTDC for display and audio playback (via FATFS). The issue seems to stem from a conflict in clock configurations.

My setup: 

    MCU = STM32F469i-Disco

The problem

When I configure the clock for LTDC like this:

LTDC clock configuration (stm32469i_discovery_lcd.c line 342):

 

 

 

PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_LTDC;
PeriphClkInitStruct.PLLSAI.PLLSAIN = 384;
PeriphClkInitStruct.PLLSAI.PLLSAIR = 7;
PeriphClkInitStruct.PLLSAIDivR = RCC_PLLSAIDIVR_2;
HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct);

 

 

 

The display works perfectly, but the audio playback through FATFS fails (specifically in Audioplayer.c at line 42).

However, when I comment out the LTDC clock configuration:

// PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_LTDC;

The audio playback works again, but the display shows an artifact—a black line appears on the screen (as shown in the attached image).

 

LTDC Timing Configuration:
Timing Configuration:

 

hltdc_eval.Init.HorizontalSync = (HSA - 1);
hltdc_eval.Init.AccumulatedHBP = (HSA + HBP - 1);
hltdc_eval.Init.AccumulatedActiveW = (lcd_x_size + HSA + HBP - 1);
hltdc_eval.Init.TotalWidth = (lcd_x_size + HSA + HBP + HFP - 1);

Initialize the LCD pixel width and pixel height:

hltdc_eval.LayerCfg->ImageWidth = lcd_x_size;
hltdc_eval.LayerCfg->ImageHeight = lcd_y_size;

 

My question:

How can I resolve this conflict so that both the LTDC display and audio playback work simultaneously without any artifacts or errors? Is there something wrong with my clock configuration, or is there a better way to manage the clocks for these peripherals?

Any insights or suggestions would be greatly appreciated!

Thanks in advance for your help.

4 REPLIES 4

@DerFreaker wrote:

MCU = STM32F469i-Disco


That's the board - not the MCU.

The MCU is the STM32F469NI chip which is mounted on that board.

 


@DerFreaker wrote:

The issue seems to stem from a conflict in clock configurations


Seems a reasonable hypothesis - so test that hypothesis.

http://www.8052mcu.com/faqs/120313

Compare & contrast the working & not-working configurations.

 


@DerFreaker wrote:

audio playback through FATFS fails (specifically in Audioplayer.c at line 42)


What is that line? What, exactly, goes wrong there?

 


@DerFreaker wrote:

when I comment out the LTDC clock configuration:

// PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_LTDC;

The audio playback works again, but the display shows an artifact—a black line appears on the screen (as shown in the attached image).


Have you looked at the display interface lines with a logic analyser or scope to see what's happening?

@Andrew Neil wrote:

What is that line? What, exactly, goes wrong there?

 

I forgot to put my code in there im sorry for that. its happening on line 19 here or when you have downloaded the file on line you will find it in audioplayer.c on line 42 on the f_lseek function it gives me the fatfs error "FR_DISK_ERR".

 

 

uint32_t GetData(uint32_t offset, uint8_t *pbuf, uint32_t NbrOfData) {
  /*
  This function reads data from a file at a specified offset and stores it in a buffer.

  Args:
      offset: The byte offset within the file from where to start reading. (uint32_t)
      pbuf: A pointer to the buffer where the read data will be stored. (uint8_t*)
      NbrOfData: The number of bytes to read from the file. (uint32_t)

  Returns:
      The number of bytes actually read from the file. (uint32_t)
  */

  FRESULT res;
  UINT bytesRead;

  // Move the file pointer to the desired offset within the file
  // HERE!!!!!!!!!!!!!!!
  res = f_lseek(&fil_wave, offset);

  // Check if moving the file pointer was successful
  if (res != FR_OK) {
    // If there was an error, return 0 bytes read
    return 0;
  }

  // Read data from the file into the provided buffer (`pbuf`)
  // &fil is the file object.
  // pbuf is the buffer pointer.
  // NbrOfData is the number of bytes to read.
  // &bytesRead is a pointer to a variable that will store the actual number of bytes read.
  res = f_read(&fil_wave, pbuf, NbrOfData, &bytesRead);
  if (res != FR_OK) {
    return 0;
  }

  // If both operations were successful, return the number of bytes actually read
  return bytesRead;
}

 

 

And here you can see what happens.

DerFreaker_0-1723197047077.jpeg

 

@Andrew Neil wrote:

Have you looked at the display interface lines with a logic analyser or scope to see what's happening?

 

No, unfortunately I don't have a logic analyser, but I can see it on the display.

 

 

 


@DerFreaker wrote:

on line 42 on the f_lseek function it gives me the fatfs error "FR_DISK_ERR".


So step into that function to see exactly what fails, and where.

Again, have you looked at the interface lines with a logic analyser or scope to see what's happening?

 
 

So Ive stepped into the function and saw that the main problem is happening in usbh_msc.c at line 785.

MSC

 

  if ((phost->device.is_connected == 0U) ||
      (phost->gState != HOST_CLASS) ||
      (MSC_Handle->unit[lun].state != MSC_IDLE))
  {
    return  USBH_FAIL;
  }

 

 MSC_Handle->unit[lun].state is for whatever reasons on MSC_READ...

i dont know how to fix it by now.

DerFreaker_0-1723202964245.png

DerFreaker_1-1723202975696.png

@Andrew Neil @wrote:

Again, have you looked at the interface lines with a logic analyser or scope to see what's happening?

 

 

No, unfortunately I don't have a logic analyser.