STM32 HID host class library, mouse mode

[Pavel A.]

Posted on January 08, 2018 at 15:08

I've generated a new project for STM32446 with CubeMX (v. 4.23.0, repository v 1.18)

with USB in host mode and only HID class. On a custom board.

It works right 'out of the box' and detects attachment of standard PC keyboard and mice.

Then added code for polling the attached device for reports, borrowed from example app

... STM32Cube_FW_F4_V1.18.0/Projects/STM32F412G-Discovery\Applications/USB_Host/HID_Standalone

This works fine with keyboards, but not with mice. Could not get any report from several mice - Microsoft, Logitech, Mueller and few others.

Has anyone seen standard mouse working with pure Cube generated project?

Actually I need both FS and HS USB cores of STM32446 and configured both in the Cube in FS mode, host only.

Each core is wired to a USB receptacle.

The Cube properly generated two USB host instances, two app callbacks and so on.

Unfortunately I don't know much about USB or HID, just need the stuff working ASAP.

So, spent the weekend browsing the USB HID library code and made the mouse path working, with couple of ugly hacks. If someone can confirm that the library 'as is' does not work with mice, I'll post these hacks, otherwise will look for problems on my side.

More to this.... when both mouse and keyboard are connected, they enumerate correctly - but after few seconds of polling, reports from both of them go wild and garbage is received. Haven't investigated enough. It looks like a mere software issue: either some data in the libraries is 'static' rather than allocated per instance, or common stuff gets corrupted. But it may be a hardware issue?

Has anyone seen _both_ USB keyboard and mouse (or HID and other device) working together?

Regards,

-- pa

#usb-host-library #stm32f4 #usb-hid #stm32-f4

[Pavel A.]

Posted on January 08, 2018 at 15:21

Here is my added code for getting reports:

void MX_USB_HOST_Process(void) 
{
 /* USB Host Background task */
 USBH_Process(&hUsbHostHS);
 port_process(&hUsbHostHS);
 
 USBH_Process(&hUsbHostFS);
 port_process(&hUsbHostFS);
}

static void port_process(USBH_HandleTypeDef *phost)
{
 HID_KEYBD_Info_TypeDef *k_pinfo;
 HID_MOUSE_Info_TypeDef *m_pinfo;
 HID_TypeTypeDef devtype = USBH_HID_GetDeviceType(phost);
 // Poll for reports:
 switch (devtype)
 {
 case HID_KEYBOARD:
 {
 k_pinfo = USBH_HID_GetKeybdInfo(pPort->pUsbHost);
 if (k_pinfo != NULL)
 {
 handle_kbd_report(k_pinfo);
 }
 }
 break;
 case HID_MOUSE:
 {
 m_pinfo = USBH_HID_GetMouseInfo(pPort->pUsbHost);
 if (m_pinfo != NULL)
 {
 handle_mouse_report(m_pinfo);
 }
 }
 break;
 default:
 break;
 }
}
�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

-- pa

[Pavel A.]

Posted on January 12, 2018 at 23:10

What, no one tried to hook a mouse to a host with HID class ?

-- pa

[Pavel A.]

Posted on January 17, 2018 at 19:55

Update:

- The mouse not working: looks like others have related issues and ST will investigate.

https://community.st.com/0D50X00009XkX0ASAV

.

- Two HID devices together with both USB cores of STM32F4:

Caused by a trivial bug in CubeMX code generation.

It uses same global 'class' structure for both instances, but the structure has some fields that must be per-instance.

Can be solved easily as follows:

void MX_USB_HOST_Init(void)

{ /* USER CODE BEGIN USB_HOST_Init_PreTreatment */

static USBH_ClassTypeDef hidClass2; // class struct for the 2nd instance

// Clone the built-in class struct for 2nd instance:

(USBH_HID_CLASS)->pData = NULL; // ensure per instance allocated ptr is 0 memcpy(&hidClass2, USBH_HID_CLASS, sizeof(hidClass2)); USBH_Init(&hUsbHostHS, USBH_UserProcess, HOST_HS);

USBH_RegisterClass(&hUsbHostHS, USBH_HID_CLASS);

USBH_Start(&hUsbHostHS);

USBH_Init(&hUsbHostFS, USBH_UserProcess, HOST_FS);

USBH_RegisterClass(&hUsbHostFS, &hidClass2);

USBH_Start(&hUsbHostFS);

}

Regards,

Pavel A.

[Tesla DeLorean]

Posted on January 17, 2018 at 21:21

HAL does seem to have migrated more things to being globals, and having lifespan expectations beyond initialization. The clarity with which ST uses these things could be a lot better.

Really not a big fan of global stuff, or naming things uartinstance1, uartinstance2 when an array might be a better way to contain them.