I'm working on a consulting project that needs a Composite HID + Bulk device. I have many years of HID experience, being the author of HIDmaker software for Microchip devices, but I am completely new to Cypress FX3 devices and framework.
I am set up & able to compile & run stock FX3 demos, especially the HID "mouse in a circle" and BulkSrcSink demos on the SuperSpeed Explorer Kit board. I am able to capture HIgh Speed bus traffic with a Beagle 480 analyzer.
The trouble came in when I tried to make a Composite device by merging code from the Cypress cyfx3_hid demo into the cyfxbulksrcsink demo, to make a single project that contains both a Bulk Interface and a HID Interface.
I chose to use two separate threads in my merged project : one for the Bulk Interface, and the other for the HID Interface. (I have one CyFxApplicationDefine() function that calls 2 routines that create a thread for the Bulk Interface and another thread for the HID Interface. ) As I am new to FX3, I don't know if trying to use 2 threads like this was a good idea or not. I would appreciate any feedback you would care to share on that subject.
I have added many CyU3PDebugPrint() statements, to tell me which routines get called. I have tried running with both threads being created, or only one of these 2 threads being created.
I believe that I have merged the Descriptors together correctly, and have gotten the project to compile without errors, but at run time, the merged project fails in the very beginning of the run, during the bus speed negotiation phase. Here is a screen shot of a Beagle capture of the merged project with only the HID thread enabled:
You can see that in both attempts at bus speed negotiations, the device times out and suspends, but the second suspend (Index 15) is total -- the PC doesn't make any further attempt to communicate with the device. Notice the details of the Chirps in the two attempts.
By contrast, here is the beginning of a capture of the working cyfxbulksrcsink project:
This run succeeds. Notice the details of the Chirps in the two attempts -- different than in the non-working project. Notice that after the second <Full-speed> state (Item 18), the PC immediately sends a SOF and begins communicating with the device.
So the key question is "Where in the Cypress code would this speed negotiation behavior be getting screwed up in my failing merged example ???"
Another curious thing, even about this working example, is that I was connecting this SuperSpeed - capable example to a USB3 receptacle on the Windows 10 PC through a new USB 2 hub, to force High Speed communication so the Beagle 480 could capture data. But for some reason, we wind running the whole project in Full Speed. Why is that happening ?
Since this merged project is totally non-proprietary to my client, I could certainly provide the current (non-working) source code if anybody wanted to look it over.
Dr Bob Miller, Trace Systems Inc.