Reliability issue when using SDMMC & USB Serial together with STM32H750VBT6

[pacman1945]

Describe the bug
With STM32H750VBT6 running STM32duino_STM32SD Cardinfo Example, there is a reliability problem if the serial output is set to USB Serial. That is, by enabling USB Support "CDC (generic Serial supersede U(S)ART)". If USB Serial is enabled, there is over 50% chance card.init() fails.

If I disabled USB Serial and use the Generic Serial (PA10 & PA9), the CardInfo Examples worked perfectly every time. The reliability problem only occurs when running the Cardinfo with USB Serial.

To Reproduce
Install the latest version of STM32duino_STM32SD (v1.2.3) and FatFs (v2.0.3) via Arduino Library Manager.
Choose example STM32duino STM32SD->Cardinfo
Modify the baud rate to 115200
Enable: USB Support "CDC (generic Serial supersede U(S)ART)"
Run the Cardinfo example
Open the "Serial Monitor"

Screenshots
When it fails, the following message will be displayed.

Initializing SD card...initialization failed. Is a card inserted?

Desktop (please complete the following information):

• OS: MacOS
• Arduino IDE version: 1.8.8
• STM32 core version: 2.0.0
• Tools menu settings if not the default: Board part number: Generic H750VBTx
  USB Support "CDC (generic Serial supersede U(S)ART)
  Default for other items
• Upload method: SWD

Board (please complete the following information):
STM32H750VBT6 from the below URL
https://www.aliexpress.com/item/1005001683272407.html?spm=a2g0o.productlist.0.0.637d1d300fFQ5d&algo_pvid=b237e656-d04b-422e-84af-8be8ed4042d9&algo_expid=b237e656-d04b-422e-84af-8be8ed4042d9-0&btsid=0bb0624116200479098028721ef47f&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603

[pacman1945]

Additional Info: I've performed the same test on a STM32H743VIT6 board and it worked perfectly. The described problem only occurs on STM32H750VBT6.

[fpistm]

Hi @pacman1945
the generic variant are provided "as it".
The generic variant for MCU's you mentioned are the same.
Main difference is the Crypto/hash processor but Arduino does not deal with it.
I guess you should have a look to Errata sheet maybe the difference are here.
I advise also to customize USB and SD PinMap arrays as all pins are available and configured by default (iteration on all pins available in the array) but not all are really useful. USB SOF/ID/VBUS and for SDMMC only the used pins are required.
It is planned, to split those tables per signal to init only the requested one as I've done for QSPI/OSPI.

One other test you can perform is to disable the ICACHE and DCACHE using build_opt.h:
-DI_CACHE_DISABLED -DD_CACHE_DISABLED

[pacman1945]

I checked the Errata sheet for STM32H750xB vs STM32H743xI/G. They’re basically the same. I’ve also tried to disable ICACHE & DCACHE, but problem still persisted.

However, I noticed that the marking on my STM32H750VBT6 says “VBT6 Y” on the 2nd line, while my other STM32H743VIT6 has marking of “VIT6 V”. I would guess the Y & V are the silicon revisions. If so, my H750VBT6 is an older silicon of revision Y, and my H743VIT6 is a newer silicon of revision V.

I’ve checked another document “AN5312 Application note” on Migration from RevY to RevV for STM32H743/753 and STM32H750. There is a section discussing the update on USB controller, but I’m unable to fully understand the technical details and its effect. Maybe the problem that I encountered is related to the silicon revisions.

[pacman1945]

I've noticed there are some changes in RCC registers from Rev Y to Rev V (AN5312, p8). The HSITRIM bits have been moved from RCC_ICSCR to RCC_HSICFGR & RCC_CSICFGR registers. It seems to me the STM32duino Core code is catered only for Rev V silicon. The file "stm32/2.0.0/system/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_rcc.c" assumes the HSITRIM bits in RCC_HSICFGR register, which isn't true on the old Rev Y silicon. Could this cause problems?

[fpistm]

Yes I guess it is possible.

[fpistm]

Just thinking that the system clock config configure the board to run at 480 MhHz but only the rev V can obtained this.
You should try to change the clock config to lower the CPU freq.

[pacman1945]

I've already tested using HSE clock running at 400MHz, but the reliability issue still existed.

[fpistm]

OK I thought it wad set at higher speed. Made too much variant last months...😉
So hard to tell exactly where is the exact issue. Even if errata sheet are basically the same, maybe on H750 some of them can be more visible.
As it is the same variants the only differences I can see is the HAL or CMSIS devices.

[pacman1945]

Just to clarify, the default is using Internal Crystal (HSI) with SYSCLK set at 480MHz. I've modified the HSI SYSCLK to 400MHz, same issue. I've also tried to use External Crystal (HSE) and SYSCLK set at 400MHz, same problem.

[fpistm]

So I'm not so mad 😉
One other possibility is an issue linked to the board. Did you try to retry when the init failed at sketch level ?

[pacman1945]

The Cardinfo Example sketch is already doing retry indefinitely. BY THE WAY, when it fails, the card.init() call would block for around 1 minute before returning. Subsequent retry would always fail, but returned immediately without blocking.

  while(!card.init(SD_DETECT_PIN)) {
    if (!disp) {
      Serial.println("initialization failed. Is a card inserted?");
      disp = true;
    }
    delay(10);
  }

[fpistm]

Hi @pacman1945
Please, could you test with #1393?

[pacman1945]

I've re-tested the Cardinfo Example with your new patch. With the default generic_clock.c, the Cardinfo Example failed every single time. First, I thought maybe 'cos the sysclock was at 480MHz. Then, I modified it to 400MHz and it still didn't work, not even once.

Afterwards, I copied the generic_clock.c from previous version (that is, from the official 2.0.0 release) and it worked intermittently, just like before. I've also tried change the sysclock to 400MHz, and it also worked intermittently, exactly as before.

Conclusion:

• With the patch from fix: generic H7: clock configuration #1393 and the old generic_clock.c, the reliability issue remains the same. That is, the Cardinfo example sometimes works, sometimes doesn't.
• With the patch from fix: generic H7: clock configuration #1393 and the new generic_clock.c that came with it, the Cardinfo example didn't work at all, even with sysclock running at 400MHz.

[pacman1945]

Okay, I can now get the patch from #1393 and the new generic_clock.c that came with it to work intermittently by modifying the clock config as follows:

50c50
<   RCC_OscInitStruct.PLL.PLLN = 60;
---
>   RCC_OscInitStruct.PLL.PLLN = 50;
52c52
<   RCC_OscInitStruct.PLL.PLLQ = 5;
---
>   RCC_OscInitStruct.PLL.PLLQ = 4;

Previously, I only modified the sysclock to 400MHz by changing RCC_OscInitStruct.PLL.PLLN to 50. This will result in SDMMC clock running at 160MHz. This time, I also modified RCC_OscInitStruct.PLL.PLLQ to 4, so as to set the SDMMC clock to 200MHz. When sysclock running at 400MHz and SDMMC clock running at 200MHz, I can use the new generic_clock.c and everything behave exactly like before. That is, it works intermittently. However, this new patch still didn't fix the original reliability issue.

BY THE WAY, are you able to get a STM32H750VBT6 for testing?

[fpistm]

BY THE WAY, are you able to get a STM32H750VBT6 for testing?

Unfortunately, I don't have one.

As you mentioned

Additional Info: I've performed the same test on a STM32H743VIT6 board and it worked perfectly.

My guess is it is linked to the HW, probably one issue listed in the errata sheet.

[fpistm]

Hi @pacman1945
I've got a WeAct MiniH750VBT6 which has been added to the core.
So, I do the test with it and I have no issue with SDMMC and USB Serial. I've tested several time with the WeAct variant and the generic one.
I've tested on the top of the main branch, I know some issue around H7 have been done so maybe one of them helps on this is your board which have an issue.

I close this issue as I could not reproduce.