STM32F746G-DISCO : USB host HID standalone demo application doesn't work anymore in 1.17

[MrBlueXav]

Describe the set-up

• The board : STM32F746G-DISCO MB1191B
• IDE : STM32CubeIDE 1.11.2
• STM32CubeF7 1.17

Describe the bug In USB host HID standalone demo application for STM32F746G-DISCOVERY kit : The keyboard is recognized but when you type, no character is displayed. (neither on FS or HS connectors) It used to work in versions 1.16 and 1.16.2

How To Reproduce

1. Run the application.

[TheNeverK]

Hi, I have encountered the same problem, also using the STM32F746G-DISCO. It seems that there is something wrong in the STM32_USB_Host_Library - specifically the Core part. The issue can be mitigated by replacing files in the Core folder with ones provided with 1.16.2 version of STM32CubeF7. Similar problem occurs in the Audio_playback_and_record demo, where the application requires an USB drive to function. With version 1.17 of the USB host library it gets stuck in an infinite loop while trying to get vendor and product info about the drive. This doesn't happen with the library provided with version 1.16.2. In my tests I used a freshly generated demo project from version 1.17 and replaced only USB Host Library from 1.16.2. So far i didn't have time to locate exactly what in the library causes this to happen, but surely by looking at the diffeneces in the source code between versions it should be easy to isolate and fix.

[MrBlueXav]

Thank you TheNeverK ! The "audio playback and record" application doesn't work either with 1.17 !

[davidzwa]

Noticing my STM32F756ZG dev board is not receiving any mouse HID events as well. Switching to 1.16.2 was very problematic @TheNeverK and comparing it with 1.17.0 is a huge task.

[kaamil1984]

I had similar issues with STM32F722ZE NUCLEO.

I had old Cube IDE 1.9.0 with 1.16.2 package and it worked on that package.

For testing purposes I have created identical projects with 1.16.2 and latest 1.17 version.

Version generated with 1.16.2 was ok. Version generated with 1.17 was NOT OK.

By NOT OK I mean that in the usbh_hid.c I was not able to reach callback in debugger, because USBH_LL_GetURBState(...) was always false.

if (USBH_LL_GetURBState(phost, HID_Handle->InPipe) == USBH_URB_DONE)
      {
        XferSize = USBH_LL_GetLastXferSize(phost, HID_Handle->InPipe);

        if ((HID_Handle->DataReady == 0U) && (XferSize != 0U))
        {
          USBH_HID_FifoWrite(&HID_Handle->fifo, HID_Handle->pData, HID_Handle->length);
          HID_Handle->DataReady = 1U;
          USBH_HID_EventCallback(phost);

#if (USBH_USE_OS == 1U)
          phost->os_msg = (uint32_t)USBH_URB_EVENT;
#if (osCMSIS < 0x20000U)
          (void)osMessagePut(phost->os_event, phost->os_msg, 0U);
#else
          (void)osMessageQueuePut(phost->os_event, &phost->os_msg, 0U, NULL);
#endif
#endif
        }
      }

This problem is easy to reproduce. Just make default F722 NUCLEO project with default peripherial, just switch USB to Host Only, enable USB HID, connect mouse or keyboard, put a breakpoint on USBH_HID_EventCallback(phost);.

Tried to compare whole generated code with git, but there are a lot of not functional changes with naming and casts and it was too hard for me to catch functional changes because I'm not an expert in the USB world.

[MrBlueXav]

I found that many ST demo applications wouldn't work any more, even BSP examples with Cube F7 1.17 and H7 1.11 downloaded packages. This is very frustrating for a beginner... I finally worked that around by using latest files from the Github repositories : HAL, USB, BSP which seem to live and develop independantly from main Cube. I know it is not recommanded by ST but that worked for me ! Xavier

[ALABSTM]

Hi everyone,

Please excuse this delayed reply. Looks this issue is the same as this one. Normally, this should be fixed in the next release. I'll keep you updated.

With regards,

[ALABSTM]

ST Internal Reference: 161601

[ALABSTM]

Hi again,

As suggested by @MrBlueXav, the fix has already been published in the stm32f7xx_hal_driver repository. Thanks to the use of submodules (see this post), you can also have the same fix in this repository.

With regards,

[ALABSTM]

Fixed in commit 7f25a108012707cc7a643a6bee79947bd068e0ab