STM32H742 intermittent SD card lockup

[embeddedvoyager1nova]

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

FATFS settings with DMA template enabled in advanced settings

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.

[AScha.3]

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. 

[embeddedvoyager1nova]

Running in 1bit mode, no DMA, at 9.6MHz returns inconsistent FR_DISK_ERR on f_open and f_reads very quickly. The circuit for the SD card is as follows:

The pullups are 47k.

[AScha.3]

So now the most "easy" mode for the CPU.

Indicating to a hardware problem.

1. How long are the lines CPU to SD-card?

2. Pin mode/ speed of pins for SD-card?

3. Supply at 3v3 is clean, no spikes?

Maybe cap could help, I have 10uF cer cap close to the SD-card.

4. Clk speed for card, I use 100Mhz , div 1, so 50M for SD-card, maximum here.

[embeddedvoyager1nova]

1. the SD traces are only about 13mm from MCU to SD card slot

2. 

3. Yes

I could try tacking a cap to SD_VCC. This is the circuit that provides power and allows me to toggle power for a hard reset:

I understand that the SD card not working properly in 1b mode points to a hardware issue, however, this is not the first SD card/implementation that I have worked with as I use them quite regularly on other boards. I am only really having problems on this processor specifically between 2 different boards specifically using the H7 processor. I feel like I might be missing something in software that I am not considering.

[AScha.3]

Ok, but pin speed could be a problem;

try medium or medium/high and pullups ON on all lines to card.

At high speed these CPU pins switching so fast, that reflexions and ringing even on short tracks can cause big problems, try slow ...as possible, to rule out these kind of problems.

And clock for sdmmc module?

[embeddedvoyager1nova]

I will run tests at medium with pull ups on all of the lines. Most lines already have an external pullup.

Fed clock to SDMMC is 48MHz

with a 4 for clock div for current testing:

I have tried 0-4 for clock div to be within "standard" operating speeds and safe operating speeds for SD cards.

[AScha.3]

Make pullups ON anyway.

And clock can be at max, 50 or 48 M , will work fine always.   ....  or never. :). 

[embeddedvoyager1nova]

Adding pull ups to all of the lines does not appear to resolve the intermittent issue unfortunately 

[AScha.3]

So just do it without any theories behind.

( It might help, by changing the pin impedance at high frequency, if reflection is part of the problem. )

Or just do, what's perfect in your theories.