STM32H753 UsbX MSC + SDMMC DMA

[DZimm.9]

Hi all,

I'm currently working on a project using a STM32H753 in combination with the Azure RTOS UsbX to create a composite class USB device (CDC ACM + MSC). 

As a starting point for the MSC support, I'm using this STM github example:
https://github.com/STMicroelectronics/x-cube-azrtos-h7/tree/main/Projects/STM32H735G-DK/Applications/USBX/Ux_Device_MSC 

Unfortunately, my board only supports a 1-bit SD bus which is running at 48MHz. 

The composite class is working along I'm using the HAL_SD_WriteBlocks_IT / HAL_SD_ReadBlocks_IT functions. By using the IT driven approach, Windows is able to mount the SD card and I can create, edit or delete files as expected.

Changing to the DMA driven functions, then the mount seems to fail, has corrupt disk naming or asks to insert a disk. I'm aware of cache coherency issues in the H7 and I setup the linker file and MPU accordingly (creating an 32kB area for the UsbX memory pool in the AXI SRAM):

 

Linker file:

/* Specify the memory areas */
MEMORY
{
...
 USB_D1 (xrw)			: ORIGIN = 0x24077000, LENGTH = 32K
...
}

 /* USB RAM section */
 .usb_sec (NOLOAD) : {
 	/* Place OTG PCD handle section at start of USB_D1 */
 	. = ORIGIN(USB_D1);
 	*(.UsbHpcdSection)
 	
 	/* Place UsbX memory pool here - max 28kB */
 	. = ORIGIN(USB_D1) + 0x1000;
 	*(.UsbxPoolSection)
 } > USB_D1 AT> FLASH

In the linked example above, the PCD handle was also placed in a non cacheable region. Is this actually needed?

As usual, the memory pool (16kB) is then placed in the defined section:

/* USER CODE BEGIN UX_Device_Pool_Buffer */
__attribute__((section(".UsbxPoolSection")))
/* USER CODE END UX_Device_Pool_Buffer */
__ALIGN_BEGIN static UCHAR ux_device_byte_pool_buffer[UX_DEVICE_APP_MEM_POOL_SIZE] __ALIGN_END;
static TX_BYTE_POOL ux_device_app_byte_pool;

Furthermore, I'm using test point on PCB to monitor the activation of the USB interfaces (CDC and MSC) and use pins to track read write operations on the MSC interface.

The patterns look very similar for IT and DMA driven communication.

IT driven:

DMA driven:

In case of the IT driven approach, the reading activity completely stops once Windows has mounted the drive. In case of the DMA, the access continues indefinitely:

So, after a few days of searching, I was wondering if anyone can spot an issue with this setup or if there is any errata which I missed regarding the UsbX / SDMMC / DMA on the STM32H7. 

Any additional insight where to dig deeper is greatly appreciated :)

Thanks and best regards

Daniel

 

 

 

[AScha.3]

Hi,

i cannot explain - but i found :

(old) project, working fine , no IDMA, tried to "improve" : migrate to actual IDE and H7-libs, and with DMA - nothing, not working. Without DMA, fine, no problem .

So i made a simple test project: on same hardware (board with H743, sdmmc 4bit mode), actual IDE and H7-libs, 

just mount and read directory;

without DMA ok;

then with DMA setting: fine ! no problem at all.

Hmmm...maybe, because i read in prog a lot of data, not only small test ? So made the test prog reading 128KB block from file : also no problem with DMA. 

Then again in the full program: no, with DMA setting not working. SD-card has no problem, but on read its waiting for data, but nothing comes and it waits til timeout. 

Until now i could not find out, whats the difference (and my prog still reads SD without DMA :) ).

[FBL]

Hi @DZimm.9 

Would you attach minimum firmware to reproduce the issue on a reference board?

[DZimm.9]

Hi,

Thanks for your feedback.

In the meantime, I hooked up a SD card socket to the NUCLEO-H753ZI to check a different hardware / SD card. I will share my findings and some minimum firmware once the NUCLEO project is setup.

Best regards

Daniel

 

 

[DZimm.9]

Hi,

I stripped down and migrated my main application to the NUCLEO-H753ZI to provide a minimal firmware example. The code is available on github: https://github.com/NoyzZimmi/STM32H7_MSC_CDC

The issue is reproducible with the NUCLEO, meaning that as soon as I add the MSC to the project / composite class, the USB device fails to enumerate and the SD card isn't mounted properly. 

Yellow / red: Activate / Deactivate signals of CDC and MSC
Green: Read activity of MSC read function:

Furthermore, I checked signal integrity and timings of the SD card interface and everything seems to be in order:
SDMMC clock is configure to 192Mhz (PLL1Q from 4MHz) and with the CLKDIV of 5 it results in a 19.3MHz CLK:

Overshoots can be reduced by GPIO speed from "Very high" to "High" / "medium", but it should already be fine for all three speeds. SDMMC CMD gpio speed - very high and low speeds:

Few questions:

- Is it true that OTG_FS FIFO is 4kByte in the STM32H753? Or is this only true if in HS mode? (I found table 509 in the RM which defines 4kB SRAM for OTG_HS2 FIFO)

- I added callbacks for the HAL_SD_ErrorCallback handling and registered a USBX error callback to the NUCLEO project, but non of these callbacks get triggered. Is there any additional way to find out why the USB device got deactivated? 

Thank you and best regards

Daniel

 

 

 

[DZimm.9]

Hi again,

I enabled TraceX for more indepth debugging. It seems that shortly before the USB gets deactivated, the MCU hangs twice in an Interrupt calling ux_trace_device_stack_clear_feature function:

Execution profile confirms this:

And stack usage seems to be fine as well:

Best regards

Daniel

 

 

 

 

 

 

 

[DZimm.9]

Hi @FBL 

Did you have a chance to take a look at the provided firmware project?

Thank you and best regards

Daniel

[DZimm.9]

Hi @FBL / @AScha.3 

For a future reference, after digging for a very long time, I finally found the issue causing the SDMMC DMA to fail silently and corrupting the SD card. And of course it was a MPU configuration / cache consistency problem :(

In the first post I provided the USBX pool memory region definition at the address 0x24077000 with length 32K:

/* Specify the memory areas */
MEMORY
{
...
 USB_D1 (xrw)			: ORIGIN = 0x24077000, LENGTH = 32K
...
}

Configuring the MPU for this address and length does not work properly as according to ARM, the MPU region base address must be aligned to the region size:

https://developer.arm.com/documentation/dui0646/c/Cortex-M7-Peripherals/Optional-Memory-Protection-Unit/MPU-Region-Base-Address-Register

This is a very important bit of information, which I have not found in any STM documentation / application notes... it  might be even wise to add this check to the CubeMX MPU configuration tool to throw a warning when the address is misaligned to the region size.

Best regards

Daniel

[FBL]

Hi @DZimm.9 

An internal ticket 216861 is submitted to dedicated team to improve CubeMX, MPU configuration base address alignment.