How to deal with 'FX_MEDIA' in standalone HOST (not device) MSC with USBX and FILEX

NotMark · ‎2024-10-01

I am on an H573 and trying to rd/wr a file on a fat32-formatted USB memory stick using the mass storage controller.

To jump right into the problem (details further below), I am trying to understand what to do about this block when I am running in standalone mode. This snip comes from the example code which is in RTOS mode. I want standalone mode.

--Background--

As a starting point, I grabbed the Ux_MSC_Host example, and got that working with no difficulties on the H573 dev kit MB1677. That demo uses FileX, UsbX, ThreadX, and some power delivery peripherals.

Then I started some changes:

I now have hardware that does not have power delivery. There is a 5v rail turned on and powering the memory stick.
For various reasons I do not want ThreadX enabled; so:
1. I setup FileX and UsbX, and added some short snips in main.c, to finish initialization and loop on _ux_host_stack_tasks_run.
2. With this, I am able to enumerate and get into the ux_host_event_callback.

But...

When I tried to implement something meaningful in UX_DEVICE_INSERTION status, it turns out that the expression

 media = &storage_media->ux_host_class_storage_media;

fails to compile because the type "FX_MEDIA" is undefined. I need FX_MEDIA so I can use functions like fx_file_open or fx_file_read.

Apart from the undefined type, the field itself is if-def'ed away within ux_host_class_storage.h:

typedef struct UX_HOST_CLASS_STORAGE_MEDIA_STRUCT
{
#if !defined(UX_HOST_CLASS_STORAGE_NO_FILEX)
    UX_MEDIA ux_host_class_storage_media;
    ULONG ux_host_class_storage_media_partition_start;
    VOID *ux_host_class_storage_media_memory;
    ULONG ux_host_class_storage_media_status;
    ULONG ux_host_class_storage_media_lun;
    ULONG ux_host_class_storage_media_sector_size;
#else
    struct UX_HOST_CLASS_STORAGE_STRUCT
    *ux_host_class_storage_media_storage;
    ULONG ux_host_class_storage_media_number_sectors;
    USHORT ux_host_class_storage_media_sector_size;
    UCHAR ux_host_class_storage_media_lun;
    UCHAR ux_host_class_storage_media_status;
#endif
} UX_HOST_CLASS_STORAGE_MEDIA;

and the #defines are set earlier:

#if defined(UX_HOST_STANDALONE) && !defined(UX_HOST_CLASS_STORAGE_NO_FILEX)
#define UX_HOST_CLASS_STORAGE_NO_FILEX
#endif

I thought maybe I could tweak this vendor file (slightly queasy about that). But that's when I found statements like this littered throughout the library:

I want FileX (and picked it in Cube), so this #define is confusing. I guess the question is: what is the proper configuration of #defines to bring all these pieces together properly? Or is standalone host msc not a supported feature? Are there lib tweaks I can make that will fake it?

I have found these informative - but they vary:

Lastly, I attached the ioc and a pdf with recap/screenshots of what I changed.

Joe WILLIAMS · ‎2024-10-04

Hi NotMark

This post has been escalated to the ST Online Support Team for additional assistance. We'll contact you directly.

Kind Regards

Joe

STMicro Support

Alon99 · ‎2024-11-20

HI Joe,NotMark,

Can you tell me how this problem was finally solved? I also encountered this problem. Thank you.

NotMark · ‎2024-11-20

Hi Alon99,

ST automatically opened a support ticket and gave some additional help (appreciate their proactiveness!).

It sounded like there is a way to do this that involves using Cube for initial generation and then removing its RTOS manually. Exactly what that involves, or how much maintenance it would cause on subsequent Cube regenerations is unknown.

I will copy details from the ticket -- maybe those can help you. However, for my use case, I ended up using the ST-provided USB host library instead of USBX. This alternate approach had a lot of examples and was very straightforward. I have it on my low priority list to revisit USBX someday, but it is not my priority right now.

Anyway, here is the ST thread:

-----------------------------------------------------------------------

(Employee)

October 10, 2024 at 9:29 PM
Are you strapped to using USBX for standalone?

If you are wondering about the implementation of USB in standalone, then I can refer you to this example:

https://github.com/STMicroelectronics/stm32u5-classic-coremw-apps/tree/main/Projects/NUCLEO-U575ZI-Q/Applications/USB_Device/CDC_Standalone

and this one:

STM32Cube_FW_H7_V1.6.0\Projects\STM32H747IDISCO\Applications\USB_Device\HID_Standalone

(Customer)

October 11, 2024 at 7:27 AM
USBX standalone works, that isn't the problem directly. The issue is using USBX standalone when FILEX is also enabled. I believe the current implementation is such that USBX can be standalone (without files), and FILEX can be standalone (without USBX) but when used together then THREADX is required. At least that is what I picked up from the #defines in the header files -- it appears the defines mutually exclude this combination.

USBX standalone: yes because of examples such as the CDC you provided below
FILEX standalone: yes because of examples such as SDcard that can open files
USBX standalone + FILEX standalone: ???

I liked the USBX library API better than other alternatives I evaluated, but the specific usecase is integrating a usb stack into a preexisting code base, and that code already has a preexisting rtos, and for various reasons is not able to swap. So threadx cannot be included as part of the usb stack.

To workaround this issue, I changed directions, and integrated ST's native usb library (https://github.com/STMicroelectronics/stm32-mw-usb-host) and fatfs instead. I got those working in standalone.

If you are able to propose a way to disable THREADX, I will reevaluate the decision and look at USBX + FILEX again. Otherwise my current understanding is that the ecosystem is not technically viable given the constaints we are selecting. I'd be very happy to be proven wrong though! :grinning_face:

(Employee)
October 14, 2024 at 3:39 PM
I asked my colleague who is more experienced with the usbx and filex. It seems like he ran into runtime issues when trying to enable standalone USBX + FileX at the same time on the U0. I think the issue is mainly related to the CubeMX generator. Can you try generating the cubemx project with threadx enabled and then simply disable the threadx in the source code? Also, the legacy USB + FatFs should have no issues though.

We are in the process of fixing this, however, it will be a 1 year until that happens. I will double check on what's the status internally.

He also said, this workaround does not work in composite class, only if you use in single usb class.

Alon99 · ‎2024-11-24

Hi NotMark,

I tried for a few days and finally failed, it seems that Standalone USBX and FileX are not feasible at the moment, thanks for your reply.