AnsweredAssumed Answered

How do I fix USB SPLIT errors from the two HID devices in my composite device?

Question asked by James Pieterick on Jul 27, 2014

Hi,


I am working on a device on runs on a MK20DN512VLQ10. I am using CodeWarrior 10.4. This device is a control panel with buttons, rotary encoders and analog slider controls. The customer requirements state that the device is to have a USB composite device with a standard HID keyboard and a generic HID device that will be used to communicate button presses and control movements from the control panel to the host system. My original plan was to use the Processor Expert (PE) version of the Freescale USB Version 4.1.1 to implement this composite device. After having trouble making this work in Processor Expert, I contacted a Freescale FAE and was eventually told that I should not try to implement a composite device with the Processor Expert version of the stack. (Apparently it has not been thoroughly tested / has issues …) I was told that my best bet is to implement the device using the non-Processor Expert version of the stack.


I am now attempting to use the non-Processor Expert version of the  Freescale USB stack v4.1.1 in this PE project. I started out with the  hid_audio_video example project in the C:\Freescale\Freescale USB Stack v4.1.1\Source\Device\app_composite\hid_audio_video\cw10\kinetis_k60 folder. I am attempting to modify this code to implement a composite device using the existing hid mouse in the original example and importing the keyboard example code from Device\hid_keyboard. (I plan to convert the HID mouse to the generic device after I get the demo code working.) I have removed the audio and video devices. I dragged and dropped the requisite .c and .h files into my PE project and then got to work.


So far I figured out that the #include for file MK60N512VMD100.h in derivative.h  had to be changed. I substituted a #include for the PE generated file Cpu.h. That seems to take care of the cpu definitions. I also had to comment out a calls to the watchdog. (I'll put my own PE generated call in after I get the rest of this thing working.) 


The next thing that I discovered was that the usb ISR was not defined in Vectors.c. (Vectors.c is generated by Precessor Expert and is placed into the Generated Code folder.) I moved Vectors.c to my Sources folder to keep PE from overwriting it and manually added USB_ISR to ISR 0x59. It is going to be somewhat annoying whenever I regenerate my PE code because I will have to merge any changes from the new Vectors.c file to my personal one and then remove the newly generated Vectors.c file. (Is there a better way to do this?) The stack now builds and the unit now seems to call USB_ISR appropriately after this change. 


I updated the various config and report definition tables for the two HID devices. I also had to rework some of the tables because their structure assumed that there would be only one HID device in a composite device.


I am now at the point where the host computer can enumerate the devices and when I go into device manager it tells me that my HID keyboard and HID mouse are functioning properly. (I am able to distinguish my devices from the regular keyboard and mouse because of the VID and PID that I assigned to them.)


That's the good new. The problem comes when the devices attempt to send data to the host. The data does not get there. I have a Beagle USB 480 USB sniffer to monitor the USB traffic between the hub and the host.  According to it I get a “SPLIT error” whenever one of my two devices attempts to send data to the host.


I am adding an image of a trace from the Beagle. When you look at the trace, the mouse is on device 2 endpoint 2. The device communicates with the host through a hub that is hard wired to the k20 on the PC board. (The hub appears to be working correctly because I can get other device to connect successfully to the host through it.)


I have been looking at the code for a while and I can't seem to find a reason for this problem. Does anyone have any ideas as to how to debug this problem?


Thanks,

JP


Attachments

Outcomes