USB Generic HID+MSD Composite enumeration problems

[thcooke77]

I have a strange USB enumeration problem with a MK22FN512. It took a long time but I got the USB to enumerate properly and working, but unfortunately it only works when I have USBlyzer running to see enumeration issues. If USBlyzer is closed the device will not enumerate properly and it will always times out with a USB_PRINTF("not find interface"); in the USB_Class_Hid_Event() function in usb_hid.c.

With USBlyzer open it does the following in hid1_application_callback, and properly enumerates:

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_ENUM_COMPLETE

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_ENUM_COMPLETE

USB_HID_SET_IDLE_REQUEST

* attached is a USBlyzer capture file when it works.

With USBlyzer closed it does the following before timing out in hid1_application_callback:

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_ENUM_COMPLETE

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_ENUM_COMPLETE

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_ENUM_COMPLETE

USB_DEV_EVENT_BUS_RESET

and then times out at:

not find interface

A few things I have found is that is that with USBlyzer closed, it tries to set a configuration of 0 in:USB_Set_Configuration ()

static uint8_t USB_Set_Configuration (   uint32_t      handle,   uint8_t       config ) {   UNUSED_ARGUMENT(handle);    usbDsc1_CurrentConfiguration = (config - 1U);   return USB_OK; }

it calls this function with config = 0 which sets it to an invalid configuration.

If anyone can find anything wrong with my attached usbDsc1.c/.h I would appreciate the help. I am at a complete loss and do not understand where to look next.

Original Attachment has been moved to: USBcode.zip

Original Attachment has been moved to: Enumeration-works.ulz.zip

[thcooke77 · Accepted solution]

Correct answer at this post:

KDS3.1 + KSDK1.3 USB HID interrupt out endpoint causes enumeration errors (k22f)

Terry Cooke

[mjbcswitzerland]

Terry

Do you have a custom board and/or can you compare on standard reference HW?

There are MSD/HID composite references for the K22F512 at these links that you could load to check whether you get the same effect.

http://www.utasker.com/kinetis/FRDM-K22F.html

http://www.utasker.com/kinetis/TWR-K22F120M.html

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html

K22: http://www.utasker.com/kinetis/FRDM-K22F.html / http://www.utasker.com/kinetis/TWR-K22F120M.html

Serial Bootloader (Ethernet, USB, MSD, KBOOT, AN2295, SREC, SD-card, Memory Stick, Virtual COM SREC): http://www.utasker.com/forum/index.php?topic=1873.msg6796#msg6796 / http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF

USB User's Guide: http://www.utasker.com/docs/uTasker/USB_User_Guide.PDF

Composite USB: http://www.utasker.com/kinetis/USB_Device.html

For the complete "out-of-the-box" Kinetis experience and faster time to market

[thcooke77]

Mark,

Yes, this is a custom board. I have previously verified that the regular "MSD RAM+HID MOUSE" ksdk demo works correctly on our custom boards. My custom HID implementation was based on the HID Mouse demo originally. I just can't seem to track why running USBlyzer it works correctly and when USBlyzer is closed it no longer enumerates completely.

Terry

[mjbcswitzerland]

Terry

I haven't experienced dependencies like this.

If you can run your applicaton on one of the standard boards I can check it with a HW USB analyser and tell you what is going wrong. (Attach a binary to your post to do this).

Regards

Mark

[thcooke77]

Mark,

Here is a project (including .elf file) that demonstrates this dependency on the K22F freedom board.

With USBlyzer open it will correctly enumerate. With USBlyzer closed it will not enumerate. I really appreciate any advice or direction you can give me.

Terry

[mjbcswitzerland]

Terry

I am sorry but the binary doesn't look to run on the FRDM board - the Green LED comes on and stays on and there is no USB activity.

Tried from the KDS project but the same - I found that the debugger hits semi-hosting code breakpoints (brkp #00ab) all the time so doesn't allow it to run with the debugger.

Regards

Mark

[thcooke77]

I tested it this morning with the Segger drivers loaded in the FRDM-K22F board and it worked for me. I use the semi-hosting to print out the USB debug commands.

What do you need to get it running?

Terry

[mjbcswitzerland]

Terry

I loaded the Segger OpenSDA and then it works (with P&E OpenSDA it doesn't) - I didn't realise that it was possible to have code that only works when a certain debugger is loaded but maybe it is because the semi-hosting requires a corresponding debugger to be available to handle the breakpoints (?).

Also, it only works when debuging with KDS and not when the board is just powered by itself.

Your problem is that when the host sends a SetConfiguration (interface 1) your device is responding with a zero data paket (correct) but is it responding with a DATA0 packet, rather than a DATA1 packet and the host rejects this because it is incorrect.

After 5s or so of waiting (the device doesn't send anything else) the host restets the connection and tries again. The same repeats after the reset but sometimes also the SetAddress fails with the device returning malformed frames back - this again causes reset and it goes on forever like this (randomly failing on the SetAddress or the SetInterface).

This is also seen at the semi-hosting output:

SEGGER J-Link GDB Server V4.98b - Terminal output channel

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_ENUM_COMPLETE

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_DATA_RECEIVED

USB_DEV_EVENT_SEND_COMPLETE

got one raw packet

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_DATA_RECEIVED

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_BUS_RESET

USB_DEV_EVENT_ENUM_COMPLETE

got one raw packet

USB_DEV_EVENT_BUS_RESET

I have no explanation as to why it works with the analyser operating, unless it puts the interface into a promiscuous mode of some sort that allows receiving incorrect DATA packets (?)

Unfortunately these are fairly low-level driver problems - unless you broke something you may have uncovered latent bugs by changing the enumeration sequence length, for example.

Regards

Mark

[thcooke77]

Mark,

I have been trying to understand how to resolve this issue.

Is what you are saying is that the KSDK drivers are at fault or is there something wrong with my implementation?

Terry

[mjbcswitzerland]

Hi Terry

I can't say why there are problems without debugging the actual code - I just see that there are low(ish) level protocol errors which lead to the behavior that you have on your board and also are reproduced on mine.

This means that you have either broken something with your modifications or there are bugs in the original source that your usage has brought to light. The issues are not to do with your descriptors because these are sent correctly, unless that causes some memory corruption somewhere that then leads to subsequent problems.

If you think that it is a KSDK problem you could try at the KSDK forum or create a service request - maybe there are known issues that can be fixed or for which workarounds are know.

Regards

Mark

P.S. In case of urgent solution requirements see the following:

http://www.utasker.com/support.html

[thcooke77]

Thanks for all your help. I re-posted in the KSDK forum. Hopefully I can track this issue down.

Terry

[mjbcswitzerland]

Terry

OK, good luck.

I case you don't find a fast solution don't forget that you have an off-the-shelf complete K22 solution in the uTasker project including your USB composite device in industrially proven quality, simulation to avoid any guess work, and one-on-one coaching/support where required.

Regards

Mark

[thcooke77]

Well, I finally figured out the USB issues. For some reason using Semi-hosting to debug print to the console caused all of the enumeration issues. So by debugging the USB with printf's via Semi-hosting, I caused the USB not to work.

Fun bug to figure out!!!

Terry