Classic coremw apps USB standalone HID example on Nucleo-U575ZI-Q using IAR EW 9.10.2 not working?

[PaulBerland]

Hello!  I am another programmer that doesn't want to use the ThreadX and Microsoft Azure OS in order to implement device USB on an STM32U5 series processor, as I have some very time-critical real-time peripheral operation that I need to get working, I don't need an OS for my application, and I want to avoid all of the extra, highly complicated new code.  I am fairly used to ST's USB libraries of old and would be much more comfortable working with the classic model.

Our client is also not looking forward to writing custom Windows device drivers for a custom Vendor and Product ID, and I have read that it is difficult to get ST to sub-license a Product ID under the ST Vendor ID, let alone create another driver package for this (a CDC class), so I have chosen to implement a HID class.  Even though it runs slower, it is less installation hassle and the problem of Vendor and Product ID's is less of a problem (we have our own Vendor and Product ID, and we don't even need to write a driver file for a USB HID).

I have downloaded the USB HID standalone example from the Git Hub repository for classic U5 apps at this link: https://github.com/STMicroelectronics/stm32u5-classic-coremw-apps.  I made sure to get all the components using the "git clone" request.  I was able to open the IAR Embedded Workbench project file (~\stm32u5-classic-coremw-apps\Projects\NUCLEO-U575ZI-Q\Applications\USB_Device\HID_Standalone\EWARM\Project.eww) and was able to build the project using IAR with 0 errors and 0 warnings (Note: don't try this with STM32Cube IDE because there are libraries files involved and needed and there are no library files provided for STM32Cube IDE!)

I was able to program the Nucleo-U575ZI-Q board and run the debugger.  But when I let the program run, and then plug in a Type-C USB cable to the Nucleo board, and the other end of the cable to a PC, I do *not* see the new USB device appear inside "mice and other pointing devices" or "Human Interface Devices" inside the Device Manager of the Windows 10 control panel (with PID & VID equal to 0x5710 & 0x0483).  I have tried with 2 different Type-C USB cables including 1 that I know works and still no luck.  I see the green light next to the USB connector light up, and when I push a button, the green light goes off.

Does anyone know why the USB Standalone HID example doesn't seem to work in my Nucleo-U575ZI-Q setup?  I am surprised that an ST example doesn't work out-of-the-box.

[Pavel A.]

The "classic library" aside...

> I have read that it is difficult to get ST to sub-license a Product ID under the ST Vendor ID

IIRC for this you need to file a support request at https://ols.st.com/s/ 

> let alone create another driver package for this (a CDC class), so I have chosen to implement a HID class.

HID or CDC class are not universal models optimal for all applications. For many applications a simple "winusb" model performs better and is easier to do. 

 

[PaulBerland]

Pavel,

 

Thank you for the great suggestion.  I had never heard of the "winusb" USB class before, but I see now that this might well be the solution we will pick in the long-term.  We don't have to worry about the sub-licensing either so that would be ideal because we can use our own Vendor and Product ID and we don't need to worry about a Windows driver, and the hassle of searching for the correct COM port, etc., and we can take advantage of Bulk mode USB which is the fastest transmission speed.  I will certainly look into this.

As it turns out, the problem I was having with the example was actually THE USB CABLE.  I tried 2 different Type-C USB cables that were supplied with certain cellphones but neither of them worked.  As it turns out, I was able to get my hands on a brand new Type-C USB cable from the store that says on the package "Type-C (Sync & Charge) Cable" from Gadget Gear (2023) and now the device is seen by the Windows computer!

Paul

[PaulBerland]

Just to Anybody,

I thought it was also interesting and worth mentioning that I could change the Vendor and Product ID of the "CDC Standalone" example and the Windows 10 computer still recognizes it as a "USB Serial Device" WITHOUT the need for an actual Windows driver installation (such as .inf file, etc.)  There was a time when you needed to have an actual Windows driver installation for a Virtual COM port but now it seems that Windows 10 (and later?) allows any device with any vendor and product ID to enumerate properly as a Virtual COM Port.  This is good news.  So I could start out using a "CDC Standalone" class, develop my software using the CDC class, and transition to a "WinUsb" class in the future if I wanted to get away from virtual COM ports completely, and never have to worry about actually writing Windows drivers (except of course Windows application code).

Paul

[FBL]

Hi @PaulBerland 

Thank you for sharing your feedback. About my proposal, I thought it is already enumerated but you can't see it. It seemed the issue was just linked to your hardware setup (USB cable). Just I would like to share with you, documentation about WinUSB (which is not a specific USB class) but a generic driver supporting various USB classes, without the need to provide custom device driver to your clients.

 

[PaulBerland]

FBL,

Thank you for your suggestion.  As it turns out the problem was THE USB CABLE.  I had tried 2 Type-C USB cables that were supplied with certain cellphones and neither of them worked.  I got a brand new Type-C USB cable that is labelled "Gadget Gear 2023 Type-C Sync and Charge Cable" and it is now working.

FYI - your suggestion is problematic.  I found that the section for "Allow this device to wake the computer" is grayed out (Windows 10):


I found this under "Human Interface Devices".  This is the correct vendor and product ID:

And also interestingly, I found that under "mice and other pointing devices" (Windows 10) there is no tab for power management at all, so the instructions that you gave are also not compatible with Window 10 (or at least my instance of it):


But anyway, the problem is now basically solved because I have a system that works with the new cable I got.

Paul

[FBL]

Hi @PaulBerland 

This feature can be configured in dev_remote_wakeup in USB device desc parameters. FYI, you can find it under usbd_def.h