USB HID Receive

[c_dawg]

CW 10.4 MQX 4.0

I'm sending 14 bytes of information from my HID device to my HID Host every 60msec.  I know the HID defaults to low speed 1.5 Mb/s. I move the input to a buffer and keep getting mistakes.  What is about the setup causing me to lose data since by my calculations one of these packets should transfer in less than 200 micro seconds?

[c_dawg]

Another question related to USB HID receive….

Error in _usb_host_recv_data: 81 (hex integer)

After 415 receives using _usb_host_recv_data,  on consistanly the 416^th receive I start getting this hex integer 81 error.  Can anyone tell me what is happening?  All the data passes correctly, but I would like to know why my status is an error for every receive after 415.

[Martin_]

per usb_error.h that means USBERR_ALLOC. might mean that the host application schedules transactions faster than the transactions are executed(consumed) by the usb host stack. search USBERR_ALLOC string in usbh build project to get idea, which function may return this code during runtime.

[c_dawg]

Thanks Martin!  Taking in consideration what you said...

"One application design consideration would be, that usb functions like send() they schedule a transaction with the usb controller. After the transaction is scheduled they return immediately, but the actual transfer (USB master read from the source data buffer and write to USB bus) can occur at some time later, when usb controller has completed previous transfers. So, application should not change the data in the source buffer until they are really consumed by the usb controller."

We made the USB device send and then wait for a set_report from the USB Host before sending again.  In this situation using a millisecond timer we received correct data back and forth in sometimes under a millisecond. Obviously we saw Error in _usb_host_recv_data: 81 (hex integer) from the beginning of the receive on the host side.  Eventually the program stopped running, but the data was correct.  Now with a 60+msecond delay in addition to receiving a set_report on the device side all data passes correctly, but we get the problem stated above.  The _usb_host_recv_data: 81 (hex integer) on the 416 receive.  I would think the executed transactions would eventually catch up to the scheduled transactions, but the error is consistant from 416 to 1000.  My buffer only is going to 1000 at the moment.  I will be taking a break on this for a bit because I have another fish to fry, but I wanted to update.

[Monica]

Hello Colin,

did you get to try that out? Please keep us posted!

Best regards,

Monica.

[Martin_]

Hi Colin,

MQX is a host or a device or both ? Can you give a code example on how you're using the usb lib API ?

One application design consideration would be, that usb functions like send() they schedule a transaction with the usb controller. After the transaction is scheduled they return immediately, but the actual transfer (USB master read from the source data buffer and write to USB bus) can occur at some time later, when usb controller has completed previous transfers. So, application should not change the data in the source buffer until they are really consumed by the usb controller.

[c_dawg]

I apologize for not responding sooner.  I switched over into porting my code into my K60 prototype, but I am getting errors building my PE clock edited BSP following the Change Default Clock Settings in Kinetis BSP guide. Another topic coming soon…

Anyway, I'm developing a MQX host using USB HID.  My code is similar to the example MQX USB host HID mouse example.  My co-worker is sending data over USB using a K40 Quickstick using the Freescale USB stack as a device.  He is using an edited PE example problem mimicking, but not using HID class send.  It uses _usb_class_send() every 60 msec. Our thought the device is sending the wrong data, but a 60 msec delay should be long enough. 

[Martin_]

Hello, try to put a usb bus analyzer between the host and the device and see, where the data corruption occurs. It might be already corrupted on the bus.