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
Solved! Go to Solution.
Correct answer at this post:
KDS3.1 + KSDK1.3 USB HID interrupt out endpoint causes enumeration errors (k22f)
Terry Cooke
Correct answer at this post:
KDS3.1 + KSDK1.3 USB HID interrupt out endpoint causes enumeration errors (k22f)
Terry Cooke
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
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
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
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
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
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
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
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:
Thanks for all your help. I re-posted in the KSDK forum. Hopefully I can track this issue down.
Terry
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
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