cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H742 intermittent SD card lockup

Hello,

 

I am working on an application that uses the SDMMC peripheral to read the contents alternating audio files every 150ms. The buffers i have to store the data are large enough to store the entire file in a single burst within RAM. The problem I am running into is that intermittently, the sound "loops" indicating a lockup on the sound subsytem. I've added a small timer in SysTick in order to quantify how long and often this lockup occurs as the logic is running in a lower priority interrupt. I find that the system locks up between 300ms-1200ms. When I listen for this audibly and stop the code, I find that the code is stuck in:

if(BSP_SD_ReadBlocks_DMA((uint32_t*)buff,
                             (uint32_t) (sector),
                             count) == MSD_OK)
    {
      ReadStatus = 0;
      /* Wait that the reading process is completed or a timeout occurs */
      timeout = HAL_GetTick();
      while((ReadStatus == 0) && ((HAL_GetTick() - timeout) < SD_TIMEOUT))
      {
      }
      /* in case of a timeout return error */
      if (ReadStatus == 0)
      {
        res = RES_ERROR;
      }

 

in sd_diskio.c. The project is generated using STM32CubeMX on v1.13 of the processor's firmware. I have tried various methods of troubleshooting this including:
both polling and DMA implementations generated by Cube
increasing and slowing the clock divider for the SDMMC peripheral

enabling and disabling DMA cache maintenance and scratchpad buffers

forcing ISB and DSB while waiting on ReadStatus

defining my buffers in RAM_D1 and not DTCM while also making sure they're on 32 bit boundaries

debugging and putting breakpoints on failure conditions in HAL_SD_IRQHandler()

changing SD_Timeout in sd_diskio.c to see if the hang up time changes

verifying that the data passed to the IDMA is correct in the DMA template generated by Cube

Changing my clock source from PLL1Q running at 64MHz to PLL2R running at 48MHz

enabling and disabling DCache
internal pull ups on the SDMMC lines even though the lines are pulled by external hardware already
reinitializing the SD card

different PCBs/SD cards

changing the maximum output speed on the GPIO peripheral to Very High for the SDMMC pins

disabling LFN functionality to simplify the code execution

verified interrupt priorities

 

Nothing I seem to change changes the frequency of this problem, nor helps mask it

My interrupt priorities are as follows:

	NVIC_SetPriority(SysTick_IRQn, 0);
	NVIC_SetPriority(SDMMC1_IRQn, 1);
	NVIC_SetPriority(OTG_FS_IRQn, 2);
	NVIC_SetPriority(TIM7_IRQn, 3);
	NVIC_SetPriority(USART3_IRQn, 4);
	NVIC_SetPriority(UART8_IRQn, 5);
	NVIC_SetPriority(UART7_IRQn, 5);
	NVIC_SetPriority(USART6_IRQn, 5);
	NVIC_SetPriority(USART2_IRQn, 5);
	NVIC_SetPriority(USART1_IRQn, 5);
	NVIC_SetPriority(TIM8_UP_TIM13_IRQn, 6);

 

All of the USART interrupts in my current test are not running, and user code is being executed in TIM8 that is calling SD car functions. USB is also not initialized. TIM7 is a timer for a DAC to play audio from my buffers

Cube SDMMC settings, with SDMMC1 global interrupt enabled

image.png

 

FATFS settings with DMA template enabled in advanced settings

embeddedvoyager1nova_0-1778703730014.png

 

I have spent weeks trying to troubleshoot this issue across multiple projects using the same processor or one in the family, but it keeps peaking it's little head. Any idea on what I could be missing?

 

Any help would be appreciated.

1 REPLY 1
AScha.3
Super User

Hi,

as i have an audio player running now, with H743 playing from SD card, i know about...

99% hardware problem, pin speed, 1/4bit mode, DMA....whatever, all is possible.

I would recommend: test SD card reading at first, 1 bit mode, no DMA . Check speed...

if perfect, try 4bit mode . (I had problems even with 30mm too much wire...) so how looks your system ? show pic. 

If you feel a post has answered your question, please click "Accept as Solution".