cancel
Showing results for 
Search instead for 
Did you mean: 

Why does CubeMX for the STM32H743i_EVAL board put the cart before the horse and completely ignore the BSP code when the SDMMCx is enabled?

GreenGuy
Lead

Creating the project with CubeMX for the STM32H743i_EVAL board and allowing it to generate the Initializing function and call for the SDMMC1 (or 2 for that matter), generates initialization code that attempts to power up the card without checking to see if there is a card present. Obvious failure waiting to happen. And even if there is a card present, the power On function is doomed to fail because the code never exectues the SD_MspInit wich enables all the io for communicating with the card. I am curious to know why that code is not present in the GPIO initialization functions? If that is not bad enough, it gets worse when the BSP code for SD is added to the project, it causes all sorts of compiler errors because of duplicate definitions.

1 ACCEPTED SOLUTION

Accepted Solutions
GreenGuy
Lead

Sorry, one last ops. In the stm32h743i_eval_sd.c where the BSP_SD_Init routine needs to determine which sd switch edge to interrupt on the pullup needs to be applied before detecting the card presence. So I do the BSP_IO_Init first with the Pin and Pull up assigned and then look to the card switch position and then set the input interrupt edge.

View solution in original post

9 REPLIES 9
KnarfB
Principal III

Don't know why, but STM32CubeMX doesn't know about BSP at all, which is ... bad.

KnarfB

GreenGuy
Lead

This is how I fixed it.

1) In CubeMX (from CubeIDE) go into Project Manager > Advanced and check the box under "Do Not Generate Function Call" for MX_SDMMC1_SD_Init.

2) After code is generated. comment out the line in the /* Private function prototypes:

static void MX_SDMMC1_SD_Init(void);

Note: if you regenerate, you will have to go back and comment it out again.

3) Go into the stm32h743i_eval_sd.c file and copy out the code for the function:

__weak HAL_StatusTypeDef MX_SDMMC1_SD_Init(SD_HandleTypeDef *hsd)

4) Paste the code into the /* USER CODE BEGIN 4 */ section to preserve it

and remove the __weak directive.

5) Find the useless "static void MX_SDMMC1_SD_Init(void)" that CubeMX created and comment it out.

Note: if you regenerate the code you will need to go back and comment this again.

6) In main.h insert between the /* USER CODE BEGIN EFP */ and /* USER CODE END EFP */

comments the line HAL_StatusTypeDef MX_SDMMC1_SD_Init(SD_HandleTypeDef *hsd);

7) Open the file stm32h743i_eval_conf.h and add #include "main.h" so the reference to

if(MX_SDMMC1_SD_Init(&hsd_sdmmc[Instance]) != HAL_OK) can be resolved.

The code should compile OK if I did not forget anything and you get the functionality of the eval BSP code for SD.

There is one more thing that needs to be corrected in the stm32h743i_eval_sd.c code:

1) Around line 173 where it is configuring the SD pin detect, add the following if to select which edge to detect on the SD card switch:

   if((uint32_t)BSP_SD_IsDetected(Instance) != SD_PRESENT)

      io_init_structure.Mode = MFXSTM32L152_GPIO_MODE_IT_FALLING_EDGE;

   else

      io_init_structure.Mode = MFXSTM32L152_GPIO_MODE_IT_RISING_EDGE;

Now the SD switch will be correctly sensed based on the card presence state.

Now all I have to do is figure out why the filex open and close statements are timing out.

GreenGuy
Lead

I have a better way to do this and will be posting after I solve the last issue of timeouts during filex operations.

GreenGuy
Lead

The best way I could think of to fix the errors I am getting back from the HAL sd driver is to rework the stm32h743i_eval_sd.c. The problem is that the BSP code wants to set-up use a different structure for the SD_HandleTypeDef instance. CubeMX creates this and refers to it as hsd1 where the BSP code calls it hsd_sdmmc. The HAL code wants it to be the one CUBEMX creates. So I created a global define "USE_CUBEMX" and put ifdefs around all the places in the BSP code for the sd driver (stm32h743i_eval_sd.c)

I am still getting an error when the fx_open runs but now the problem has shifted, so now I waist another week or two.

I attached the modified BSP file.

GreenGuy
Lead

The error is due to a semaphore not being set when fx_media_open is run. The semaphore is sd_rx_semaphore. It is put when the HAL_SD_RxCpltCallback is run in the fx_stm32_sd_driver_glue.c is run. However, that call back never runs. The SDMMC1_IRQHandler in stm32h7xx_it.c is handling the DMA interrupt OK. The callback not running is supposed to overload the __weak callback in the stm32h7xx_hal_sd.c. I know the code is getting compiled since the semaphore is being created in glue file. What I cannot figure out is why the correct callback is not being used.

GreenGuy
Lead

Found the problem. Since fx drivers are using their own HAL_SD_RxCpltCallback and HAL_SD_TxCpltCallback I had to tag these as __weak in stm32h743i_eval_sd.c so the routines in the fx_..._glue.c file could overload them. I also had to disable the Register Callback for SD in the CubeMX Project Manager > Advanced Settings (far right window).

Now the status returned for fx_media_open and close return OK.

GreenGuy
Lead

Still need to test the directory, read file, and write file, functions.

GreenGuy
Lead

fx_media_open,

fx_directory_default_set,

fx_directory_first_entry_find

fx_file_open

fx_file_seek

fx_file_read

All work with stm32h743i_eval_sd.c as attached.

I made a small change so there will not be two sets of __weak_HAL_SD_TxCpltCallback and HAL_SD_RxCpltCallback by using the global fx define already added by CubeMX called FX_INCLUDE_USER_DEFINE_FILE.

GreenGuy
Lead

Sorry, one last ops. In the stm32h743i_eval_sd.c where the BSP_SD_Init routine needs to determine which sd switch edge to interrupt on the pullup needs to be applied before detecting the card presence. So I do the BSP_IO_Init first with the Pin and Pull up assigned and then look to the card switch position and then set the input interrupt edge.