cancel
Showing results for 
Search instead for 
Did you mean: 

USBX Device MSC in Standalone mode

PRuss
Associate II

I'm trying to get USBX Device MSC to work in Standalone mode (without RTOS).  I loosely followed @B.Montanari 's example in https://community.st.com/t5/stm32-mcus/how-to-implement-usbx-in-standalone-mode/ta-p/614435, and also referred to a CubeMX example for Device MSC which does use an RTOS (STM32Cube_FW_U5_V1.6.0\Projects\STM32U575I-EV\Applications\USBX\Ux_Device_MSC).  I'm running this on an STM32U5 dev kit.

There are no errors, Windows recognizes the USB MSC device, and a drive shows up.  But something isn't working quite right, since Windows tells me to insert a disk, won't format the volume, and doesn't seem to recognize its size.

I'm not quite sure yet where things are going wrong, but I thought I'd see if this configuration is expected to work or if I'm overlooking any other examples before digging further...

1 ACCEPTED SOLUTION

Accepted Solutions

This was apparently caused by a bug in the USBX source.  Once I fixed it, things seem to be working.

It looks like _ux_device_class_storage_disk_wait just passes the return value of ux_slave_class_storage_media_read (and other similar functions) directly to _ux_device_class_storage_task_disk.  Here this return value is compared against UX_STATE_NEXT to check for success.  

However, comparing some additional samples and other places in the code, ux_slave_class_storage_media_read is expected to return UX_SUCCESS if successful.

BTW, while debugging through the code I also found a couple of bugs in _ux_utility_debug_log (as-is it won't even compile with the UX_ENABLE_DEBUG_LOG switch).

 

This makes me wonder whether Standalone mode and other non-mainstream features are getting much use or test time.

View solution in original post

3 REPLIES 3
Imen.D
ST Employee

Hello @PRuss ,

Try to increase the heap size or configure the USB library to use static allocation as recommended in this FAQ: USB device not recognized.

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen

Thanks for the reply.  I did increase both the heap and stack significantly, but I'm still having the same issue.

This was apparently caused by a bug in the USBX source.  Once I fixed it, things seem to be working.

It looks like _ux_device_class_storage_disk_wait just passes the return value of ux_slave_class_storage_media_read (and other similar functions) directly to _ux_device_class_storage_task_disk.  Here this return value is compared against UX_STATE_NEXT to check for success.  

However, comparing some additional samples and other places in the code, ux_slave_class_storage_media_read is expected to return UX_SUCCESS if successful.

BTW, while debugging through the code I also found a couple of bugs in _ux_utility_debug_log (as-is it won't even compile with the UX_ENABLE_DEBUG_LOG switch).

 

This makes me wonder whether Standalone mode and other non-mainstream features are getting much use or test time.