Problems with HID Host and STM32F4

[Luca Giuliodori]

Posted on November 23, 2017 at 13:09

Hi everyone,

I'm developing an HID Host application to comunicate with a own device and I'm using the NUCLEO-F446ZE board.

At the start I tried to use the HID_Standalone application in the STM32CubeF4 firmware package and then, I tried to develop a new application with STMCube configurator.

In both case I tried to connect (with OTG connector) 3 different type of mouse and 1 keyboard and no all device are able to comunicate with microcontroller:

• with Typhoon mouse 40260 the USBH_Process state machine in the usbh_core.c file of the Middlewares, blocks in the HOST_ENUMERATION state (line 462) because the USBH_HandleEnum(phost) function try to get device descriptior (line 646 same file) but the USBH_HandleControl() function read all times USBH_URB_NOTREADY state (line 600 of usbh_ctlreq.c) until HAL_HCD_Disconnect_Callback() called by interrupt.
• with Trust mouse 16144 is the same with Typhoon mouse with difference that the HAL_HCD_Disconnect_Callback() isn't called by interrupt.
• with Dell Mouse XN966 all work fine and I can see the data.
• with asus keyboard G01 KB the USBH_Process state machine in the usbh_core.c come up to HOST_DEV_DISCONNECTED where there is the BgndProcess but I can't receive data because in the HID_Handle the fifo has the tail and head at the same value.

All the previous devices are tested with PC and work fine and the board are powerd with external source.

What can be the problem and how can I fix it?

Thanks in advance

#usb-hid #usb-host #stmcube-f4-usb #middleware

[Luca Giuliodori]

Posted on December 05, 2017 at 16:56

Nobody can help me?

I continued debugging code and I saw the problem is the device send to the host STALL handshake when the host try to enumerate or, with a custom device different from previosus devices, when it call SetReport or GetReport.

I read on-line that the device return STALL handshake when endpoint is in HALT state.

What could be the problem?

[Tesla DeLorean]

Posted on December 05, 2017 at 18:35

>>Nobody can help me?

Tried your local ST Micro office, and the FAE's on staff there?

[Luca Giuliodori]

Posted on December 06, 2017 at 09:24

I contacted ST online support but I didn't receive replies.

This morning I have sent an email to my local FAE and I'm waiting an answer.

What do you mean with 'FAE's on staff there'?

Thanks in advance.

[Amel NASRI]

Posted on December 11, 2017 at 13:22

Hi ​,

Do you confirm that you have same behavior in both cases: when using

HID_Standalone application in the STM32CubeF4 firmware package or when generating your own code with STM32CubeMX?

-Amel

[Luca Giuliodori]

Posted on December 11, 2017 at 14:23

Yes I confirm that I have same behavior in both cases. I had to make some changes in the HID_Standalone beacause I haven't the TFT shield but this shouldn't cause issues for USB because the changes, are only in the code for TFT shield.

I developed my application with STM32CubeMX and following the HID_Standalone application.

This mornig I have seen that in the NUCLEO-446ZE there wasn't the xtal and the clock was provided by MCO (this could be a problem for USB that want a accurate clock).

I have mounted one 24MHz xtal, I have followed all the steps of 6.8.1 section of UM1974 and set the correct parameters in the STM32CubeMX with Clock Configuration but the problem has not be solved.

[Carmelo Raimondi]

Posted on December 18, 2017 at 14:05

Hi everyone,

I have the same problem on a custom board based on STM32F429.

I need to connect a USB keyboard to the system as an input device and some works and some don't.

I tried with 6 different keyboard and only two works (a Dell and HP keyboard) : all the others aren't recognized by the system.

I'm facing the same problem of the Trust Mouse 16144 in the original message of this thread ( 

USBH_Process state machine in the usbh_core.c file of the Middlewares, blocks in the HOST_ENUMERATION state).

The thread is marked as Resolved but I can't see any solution.

[Luca Giuliodori]

Posted on December 19, 2017 at 13:03

Yes, I contacted to change the status but nothing.

The problem isn't solved, I also contacted the on-line support but no solutions have been found.

I don't know if for you can be useful but I have added other details in further reply to Amel N.

[Amel NASRI]

Posted on December 19, 2017 at 15:27

Hello,

Please note that this question is marked for action just to keep tracking for it: it means we are working on it.

I shared the case with our USB experts who should help to do a deeper analysis.

luca.giuliodori

‌, could you please share OLS ticket number? We need it to avoid duplicating effort.

I will make a branch for the post where you are reporting possible bugs in stm32f4xx_II_usb; it should be better to manage it separately.

-Amel

[Luca Giuliodori]

Posted on December 19, 2017 at 17:39

Ok no problem and thank you for your attention. Where can I find 

OLS ticket number?

[Luca Giuliodori]

Posted on January 26, 2018 at 16:56

I have applied the

pavel_a

patch suggested in

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

and seems the USB stack works fine!

I hope, as soon as possible, ST release the USB stack with these fixs.

Regards

[SSure]

When I click the above link I get the following error : "We have changed our Community platform and the page you were looking for appears to have been moved. Please bear with us while Google and other search engines finish re-indexing our pages."

I'm stuck with the same issue, so could you please help in re-directing me to the proper link?

Thanks in advance

[Luca Giuliodori]

Yes it's true: the link doesn't work.

I have not tried anymore but may be ST has released a new version of the stack with these patches. You've tried?

[SSure]

The suggested fix mentioned in the above link is working for me. Thank you.

[AAgha]

hi

can some one tell me which keyboards work with stm library!?

thanks for your quick reply.

[Pavel A.]

With the latest STM32F4 library (v 1.24) most legacy-compatible keyboards should work.

Also, composite devices (kbd+mouse, kbd+card reader) where keyboard is the 1st function should work.

"Works" here means that the HID reports can be read reliably.

I have not tested translation of HID codes to any non-latin layout.

-- pa

[hamed33]

I'm hopeful that my answer is useful after about 3 years!

This is because of your PCB design, not the code. Most of the microcontrollers, same as STM32F407, only have one USB port that can be configured as the Host or Device. But in the evaluation boards, the Discovery board for example, there are both the Host and Device physical ports. These ports share the D+ and the D- pins of the microcontroller. Based on USB standard, in the full-speed device mode, there is a 1.5k pull-up resistor connected to the D+ pin. If you need to use the system in the Host mode, you will be sure that this pull-up resistor is disabled based on the PCB schematic details. Each USB device (keyboard, mouse, etc) internally includes this resistor. Using this resistor the Host can detect the type of the connected USB device and the exact plug-in time. After plug-in detection, the host will start the enumeration procedure. Otherwise, the host can not detect the correct moment of device insertion and will run enumeration miss alined. In this situation, the enumeration procedure always reports some sort of errors same as USBH_busy.

You can find more details about USB wiring at the following link:

 https://www.beyondlogic.org/usbnutshell/usb2.shtml

Regards

[hamed33]

I'm hopeful that my answer is useful after about 3 years!

This is because of your PCB design, not the code. Most of the microcontrollers, same as STM32F407, only have one USB port that can be configured as the Host or Device. But in the evaluation boards, the Discovery board for example, there are both the Host and Device physical ports. These ports share the D+ and the D- pins of the microcontroller. Based on USB standard, in the full-speed device mode, there is a 1.5k pull-up resistor connected to the D+ pin. If you need to use the system in the Host mode, you will be sure that this pull-up resistor is disabled based on PCB schematic details. Each USB device (keyboard, mouse, etc) internally includes this resistor. Using this resistor the Host can detect the type of the connected USB device and the exact plug-in time. After plug-in detection, the host will start the enumeration procedure. Otherwise, the host can not detect the correct moment of device insertion and will run enumeration miss alined. In this situation, the enumeration procedure always reports some sort of errors same as USBH_busy.

You can find more details about USB wiring at the following link:

 https://www.beyondlogic.org/usbnutshell/usb2.shtml

Regards