cancel
Showing results for 
Search instead for 
Did you mean: 

I am trying to use the FatFs middleware but get stuck in HAL_Delay() when trying to turn the power on to SDMMC. Could someone explain why this might be happening or point to a solution for this. I put the backtrace from gdb in the details.

SPate.4
Associate II

#0 0x0800add0 in HAL_Delay (Delay=2) at Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal.c:378

#1 0x0800b9ec in SDMMC_PowerState_ON (SDMMCx=0x40012c00)

   at Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_ll_sdmmc.c:316

#2 0x0800c4fe in HAL_SD_InitCard (hsd=0x2000643c <hsd1>) at Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_sd.c:428

#3 0x0800c46c in HAL_SD_Init (hsd=0x2000643c <hsd1>) at Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_sd.c:379

#4 0x08021d9e in BSP_SD_Init () at FATFS/Target/bsp_driver_sd.c:58

#5 0x0800ed46 in SD_initialize (lun=0 '\000') at FATFS/Target/sd_diskio.c:156

#6 0x080169f4 in disk_initialize (pdrv=0 '\000') at Middlewares/Third_Party/FatFs/src/diskio.c:60

#7 0x08019498 in f_mkfs (path=0x20009f5a <SDPath+2> "/", opt=7 '\a', au=0, work=0x2004fdcc, len=512)

   at Middlewares/Third_Party/FatFs/src/ff.c:5334

#8 0x08005a34 in main () at Core/Src/main.c:173

5 REPLIES 5
SPate.4
Associate II

I was able to solve this by switching to SysTick for the clock. If anyone knows a solution that doesn't require switching to a SysTick, that would be greatly appreciated.

Not really much to work with here.

Which TIM vs SysTick?

What are the relative priorities/preempt levels for the interrupts?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Not adding anything to the answer. But if you read HAL_Delay's source code, you'll recognize it needs something to periodically interrupt and increment the tick variable. So it needs a TIM or SysTick and it needs to be able to interrupt.

Javier1
Principal

if you call HAL_delay() inside an interrupt with higher priority than your sistem tick source (systick or tim) it will wait indefinetly for the ticks that will never happen

And effectively stall your program.

we dont need to firmware by ourselves, lets talk
saeed.poorjandaghi
Associate II

It sounds like that you're using RTOS and calling f_mount function when _FS_REENTRANT macrro is enabled (=1) will call ff_cre_syncobj function is syscall.c to create a new sync. object. If f_mount function is called before RTOS init functions it can cause this type of issue. I would suggest that you move f_mount function into your idle task init section.