Is there any way to change HAL's SDMMC_DATATIMEOUT?

[CKugl.1]

My system has a user-removeable SD Card. If there is a problem with the card at initialization time, the system gets stuck looping in

SD_FindSCR() at stm32l4xx_hal_sd.c:3,970 0x8039632	
SD_WideBus_Enable() at stm32l4xx_hal_sd.c:3,822 0x803947a	
HAL_SD_ConfigWideBusOperation() at stm32l4xx_hal_sd.c:2,643 0x8038db0	
BSP_SD_Init() at sd_diskio.c:190 0x8025d18	
SD_initialize() at sd_diskio.c:225 0x8025da4	

specifically here:

  while(!__HAL_SD_GET_FLAG(hsd, SDMMC_FLAG_RXOVERR | SDMMC_FLAG_DCRCFAIL | SDMMC_FLAG_DTIMEOUT | SDMMC_FLAG_DBCKEND))
  {
    if(__HAL_SD_GET_FLAG(hsd, SDMMC_FLAG_RXDAVL))
    {
      *(tempscr + index) = SDMMC_ReadFIFO(hsd->Instance);
      index++;
    }
 
    if((HAL_GetTick() - tickstart) >=  SDMMC_DATATIMEOUT)
    {
      return HAL_SD_ERROR_TIMEOUT;
    }
  }

Is there any way to override the

#define SDMMC_DATATIMEOUT                  ((uint32_t)0xFFFFFFFFU)

in stm32l4xx_ll_sdmmc.h?

I'd rather not edit the code generated by SMT32CubeIDE.

STM32CubeIDE

Version: 1.11.0

Build: 13638_20221122_1308 (UTC)

Board Name NUCLEO-L4A6ZG

Generated with: STM32CubeMX 6.5.0

MCU Series STM32L4

MCU Line STM32L4x6

MCU name STM32L4A6ZGTx

MCU Package LQFP144

[AScha.3]

1. why not just:

#undef SDMMC_DATATIMEOUT

#define SDMMC_DATATIMEOUT ((uint32_t)0x00FFU)

[Tesla DeLorean]

Probably not without editing something.

You're going to have to take ownership of the code/behaviour and make it work in manner suitable for commercial deployment.

Does the system have a card detect method?

[AScha.3]

yep, most micro-sd-card-holders have a small switch, to check, card in or not.

but i came to same problem just 2 days ago: sd-card suddenly dead after 1y 24/7 in use.

system wait...50 days. long timeout...

no tested solution until now, but should be easy to get around.

[Tesla DeLorean]

I don't know why the implementation needs to be this sloppy.

Either parameters need to feed down from the top level, or some of these things need to live in the instance structures, have defaults, and be easy to modify during initialization.

Spinning in loops forever is not a viable error propagation and failure management strategy. So much of this code expects everything to work perfectly, and dies unhelpfully when not.

Poor testing, poor real-world usage and expectations.

[CKugl.1]

> You're going to have to take ownership of the code/behaviour and make it work in manner suitable for commercial deployment.

I don't disagree, but is HAL intended to be used only as example code? Like most generated code, it doesn't seem to be all that readable for that purpose.

[Pavel A.]

> is HAL intended to be used only as example code?

Call it "rapid prototyping"?

Changes in the ST library can be done in a controlled way - like, for example, when one needs to modify Linux drivers or kernel itself.

Keep it in a version control, branch and commit your changes.

This is maybe not for students or amateurs, but not a rocket science.

[CKugl.1]

In my opinion, the HAL should be fixed until it is useable for real applications. As complexity has increased over the years, the trend keeps moving towards working at higher levels of abstraction. How many professionals working on 32-bit systems still code only in pure assembler? If I want to log some data to an SD card in a PC readable format, I shouldn't have to start from scratch at the register level and build up to something that can run a file system. It is a complex problem but one that has been solved many times over. There's no percentage in reinventing it. I have more interesting problems to solve. This product is expected to do more than just log data.

Then there's the issue of things like Mbed OS, which depends on a working HAL. Love it or hate it, if you stay in this business long enough you'll probably have to deal with it someday .

Anyway, sorry for the rant. To answer the question:

> Does the system have a card detect method?

I oversimplified a little, trying for clarity. This system actually has three SD cards, only one of which is user accessible. That one is behind a cover with an interlock switch which provides an interrupt that lets us know that the card might be swapped (and, for other reasons, must be powered down before the user can touch it). None of the sockets have an actual Card Detect switch hooked up, to save I/O pins.

I have done some more experimentation, and I find that if the card is absent, the initialization fails and returns without getting stuck in that loop. So, what is going on when the card is present? Well, after a lot of digging, it looks like when I upgraded from STM32CubeMX 6.5.0 to STM32CubeMX 6.7.0 it broke the generated SDMMC initialization code. I have opened Case Number 00168816 for that issue.

[CKugl.1]

This is my port of ST's FatFs_uSD_DMA_RTOS FatFs with uSD card drive in RTOS mode application (https://github.com/STMicroelectronics/STM32CubeL4/tree/master/Projects/STM32L476G-EVAL/Applications/FatFs/FatFs_uSD_DMA_RTOS) example in STM32CubeIDE Version: 1.9.0, which works:

[CKugl.1]

This is my port of ST's FatFs_uSD_DMA_RTOS FatFs with uSD card drive in RTOS mode application (https://github.com/STMicroelectronics/STM32CubeL4/tree/master/Projects/STM32L476G-EVAL/Applications/FatFs/FatFs_uSD_DMA_RTOS) example in STM32CubeIDE Version: 1.11.0, which is broken: