usb host

[1Ashena M]

Posted on February 26, 2017 at 07:10

Hi Everyone,

I'm trying to read from the USB keyboard with a custom board STM32F205RCT6 MCU.

I am using USB FS host (host only) with HAL library.but it just works with some keyboards!

Other keyboards are detected by host but can not read data.

Can any one help me?

My Code:

int main(void) {  /* STM32F4xx HAL library initialization:  - Configure the Flash prefetch, instruction and Data caches  - Configure the Systick to generate an interrupt each 1 msec  - Set NVIC Group Priority to 4  - Global MSP (MCU Support Package) initialization  */  HAL_Init();    /* Configure the system clock to 120 MHz */  SystemClock_Config();  /* Init Host Library */  USBH_Init(&hUSBHost, USBH_UserProcess, 0);    /* Add Supported Class */  USBH_RegisterClass(&hUSBHost, USBH_HID_CLASS);    /* Start Host Process */  USBH_Start(&hUSBHost);    /* Run Application (Blocking mode) */  while (1)  {  /* USB Host Background task */  USBH_Process(&hUSBHost);     if(USBH_HID_GetDeviceType(&hUSBHost) == HID_KEYBOARD)  {   hid_demo.keyboard_state = HID_KEYBOARD_IDLE;   hid_demo.state = HID_DEMO_KEYBOARD; //HID_KeyboardMenuProcess();  HID_KEYBD_Info_TypeDef *k_pinfo;  char c; k_pinfo = USBH_HID_GetKeybdInfo(&hUSBHost);  if(k_pinfo != NULL) {  c = USBH_HID_GetASCIICode(k_pinfo);  char str[5]; sprintf(str,'%c',c); HAL_UART_Transmit(&huart2,k_pinfo->keys,6,10000);  }  } }�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

Result (only

detected Not read data

)

USB Device Attached PID: 1h VID: 258ah Address (#1) assigned. Manufacturer : SINO WEALTH Product : USB KEYBOARD Serial Number : N/A Enumeration done. This device has only 1 configuration. Default configuration set. Switching to Interface (#0) Class : 3h SubClass : 1h Protocol : 1h KeyBoard device found! HID class started.�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

#usb-host #usb-hid #usb-stm32f205 Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Luca Giuliodori]

Posted on June 15, 2018 at 16:24

Strange, in my case works well. Did you try to apply the

pavel_a

‌ suggestions?

[Kallil Zielinski]

Posted on June 17, 2018 at 00:10

I applied the

st.mcu

suggestion which makes alterations on both usbh_hid.c and usbh_ctlreq.c, the strange thing is that I can't initialize my USB FS without the CubeMX functions MX_USB_HOST_Init(). It's not even powering the VBus pins. I just want to make the 4 onboard leds toogle with the direction I move my mouse. It's so simple and I am getting so much problems.

Thanks

Kallil

[Tesla DeLorean]

Posted on June 17, 2018 at 01:10

Assorted participants here have had F2, F4, L4 and F7 parts.

Could we perhaps establish the model of STM32 involved, and the version of the HAL libraries, and CubeMX, being utilized?

Also the type of board, and connector being used, might also significantly tighten the problem space here.

[Kallil Zielinski]

Posted on June 17, 2018 at 01:30

Ok now I'm using F4 Discovery board. For the mouse connection I'm using the micro USB input in the board, using CubeMX v4.

[Kallil Zielinski]

Posted on June 17, 2018 at 02:06

The debug goes to the USBH_Process() function, inside it, it stops in the HOST_ENUMERATION case, which lead to theUSBH_CtlReq() function, entering on a loop, everytime the USBH_Process() function is called on my main function, it leads to USBH_CtlReq() and it returns USBH_FAIL. That is my problem, in the process to get the device description, and I already tried to change between kebd and mouse, it always goes to this point.

[Kallil Zielinski]

Posted on June 18, 2018 at 23:36

Well, now I made that 1.7V turn to 4.5V, which I think is an acceptable voltage. But even with this and disabling all kinds of optimizaions, I couldn't make this project work. But I thank all of you guys who helped me in some way. 

My project is in 

https://github.com/kallilmiguel/USB-Host

 , if any of you guys could test this project to see if it's only in my board or not.

If not, I am very grateful anyway.

Thanks

Kallil

[Pavel A.]

Posted on June 18, 2018 at 23:55

 ,

 ,

4.5 V is much better than 1.7, but still not as good as 5.0 V ...

Also,

https://github.com/kallilmiguel/USB-Host/blob/5ef8582ace718810e5ea090d0adb73f733189b46/Src/usbh_conf.c ♯ L586

 ,pin C0 is used as output, but in the Cube file it is not configured at all.

- pa

[Pokorny.Igor]

Posted on June 21, 2018 at 12:09

May be  

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

  cold help?

Igor

[waclawek.jan]

While writing my own host HID implementation I came across a stubborn keypad which I could not get working (it's not relevant to the story here but it turned out to be a slightly not standard one). So I took down from the shelf a STM3240G-EVAL, dug out a microA-to-A "OTG" cable, took STM32Cube_FW_F4_V1.21.0\Projects\STM324xG_EVAL\Applications\USB_Host\HID_Standalone\ and a bunch of "library" files it needs, hacked the eclipsoid's config file into a decent makefile, compiled, downloaded, and...

It was... well... weird.

Two of 4 tested keyboards/pads did not respond to the first setup due to delay between reset and first keepalive (https://community.st.com/s/question/0D50X00009yEQJZSA4/f4-otg-otghfir-handling second post)... and that was it. Finding: Cube does not retry setups... humm....

Okay so I fixed that and then all 4 failed at the problem described here - after enumeration in the HID_IDLE state a Get_Report request is made, and the keyboards stalled it, and again that was it. Skipping HID_IDLE as PavelA hints above omits the Get_Report request, and then polling takes place and things appear to work somehow. So I took a closer look.

The "library" seeks for boot keyboard but then sets it to report mode, and even requests the report descriptor for it. That's okay and bold, until one finds out that subsequently it ignores the report descriptor and processes data from the interrupt polls using fixed tables respective to the boot protocol... That's ehm uhm but does not explain the thing with the Get_Report request.

Looking closer at the packets on the bus, the setup transaction for that request has wLength=2. Waitaminute. Even for the boot protocol it would be 8. Now we could argue whether USB2.0 9.3.5 applies here and the keyboards should reply to such request specifying shorter length than the data actually are, or they are OK to be conservative and stall a request which has surprising wLength value; nevertheless, what would be the reason for Cube to send such smaller wLength, especially if it comes from HID_Handle->length which was previously correctly parsed out from the respective endpoint descriptor's wMaxPacket in USBH_HID_InterfaceInit()?

The real culprit is in USBH_HID_KeybdInit() where an array of 2 words i.e. 8 bytes (yes, that's no coincidence with the 8 byte long boot-protocol' report) is defined as a buffer, and then in

 if(HID_Handle->length > (sizeof(keybd_report_data)/sizeof(uint32_t)))

 {

   HID_Handle->length = (sizeof(keybd_report_data)/sizeof(uint32_t));

 }

is the place where HID_Handle->length is restricted to 2 (i.e. 2 words, although all usages of HID_Handle->length are in bytes).

(Read: the fix is to modify this to

 if(HID_Handle->length > sizeof(keybd_report_data))

 {

   HID_Handle->length = sizeof(keybd_report_data);

 }

but the real solution is still... well... yes, the painful one.

I've just noticed that this particular one was already reported in

https://community.st.com/s/question/0D70X000006SgELSA0/bug-in-usb-hid-keyboard-code

and maybe even fixed, since I did not check if there's a newer Cube around. Still,l it is just part of the whole story.

)

Now how comes that an incorrect report length results in (somewhat) working parsing of the polls, once the Get_Report request is skipped? By luckily written wrong code. The OTG machine is (according to manual) told to receive multiples of maxpacket bytes, regardless of real requested number of bytes from upper levels; so here 8 bytes are received in the interrupt poll. The interrupt poll request that data in HID_GET_DATA state to be stored into HID_Handle->pData. When they arrive, HID_Handle->length bytes (i.e. 2 bytes) are copied out from HID_Handle->pData to that weird fifo. Then, in USBH_HID_KeybdDecode(), again HID_Handle->length bytes (i.e. again 2 bytes) are copied from fifo into *the same* HID_Handle->pData (where the rest of data up to maxpacket still sits), and then all 8 bytes are duly processed...

Enjoy.

JW

PS. Later I gathered all USB keyboards I could get hand on and also asked my colleagues to bring in from home theirs for a quick test - and yes, there are keyboards which are not prone to the late-keepalives issue, there are also FS keyboards where the late SOF won't occure; and also some keyboards don't stall the wLength=2 GetReport request, reponding by the expected 2 bytes. Oddly enough, all tested keyboards indeed used the same report format in the report protocol as is in the boot protocol, in the interface marked as boot keyboard, so this appears to be some defacto "standard"; still the "library" shouldn't rely on this.

[Luca Giuliodori]

Dear @Community member​ thanks for your reply! 

I did not understand very well: two issue that you describe (the "keyboards/pads did not respond to the first setup due to delay between reset and first keepalive" and the issue with "HID_Handle->length") are related?

Can you explain better how you fixed the first bug? 

About the second one I think your suggestion is correct and I noticed that the same error is present in the previous code rows where "keybd_report_data" is set to zero.

To confirm that I noticied that in the USBH_HID_MouseInit function (in usbh_hid_mouse.c file) the code is correct.

Thanks in advance.

Luca G.