3 Replies Latest reply on Apr 1, 2019 12:15 AM by abhinavg_21

    How to fix bus speed negotiation failure?

    romic_4041961

      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:Merged_HidThread_Suspends.png

      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:

      BulkSrcSink_Connects.png

       

      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.

       

      Any suggestions?

       

      Best regards,

      Dr Bob Miller, Trace Systems Inc.

        • 1. Re: How to fix bus speed negotiation failure?
          abhinavg_21

          Hi Bob,

           

          If you are using USB 2 hub just to run the device in High Speed mode, I will suggest you to search for connectstate API in the firmware and make second argument as CyFalse. This will force the FX3 to come up as HS device.

          Also, please share the non-working code so that I can check how the threads are merged.

           

          Thanks & Regards
          Abhinav Garg

          • 2. Re: How to fix bus speed negotiation failure?
            romic_4041961

            Thanks for getting back to me on this!

            >> If you are using USB 2 hub just to run the device in High Speed mode,

            >> I will suggest you to search for connectstate API and make second

            >> argument as CyFalse. This will force the FX3 to come up as HS device.

            >>

             

            Will do!

             

            But I subsequently found / realized that there are simpler ways to force HS:

             

               

            • 1) The Beagle 480 contains a USB 2 B receptacle for the cable that

                goes from the analyzer to the host, so that in itself will force HS.

               

            • 2) I could also connect a USB2 cable into the bottom part of the USB

                3 connector on the FX3.

             

             

             

            Also, please share the non-working code so that I can check how the

            threads are merged.

             

             

            I have attached a zip file containing the entire directory tree.  Here

            is the current state of the code:

             

             

            • At the moment, I had commented out one of the calls in

            CyFxApplicationDefine( ), to only start one of the two threads. (No

            change to the problem.)

             

            • I also realize that I have created 2 versions of xx :

            CyFxUsbHidApplnInit( ) and CyFxBulkSrcSinkApplnInit( ).  Both of these

            contain CyU3PUsbSetDesc( ) calls, to the same descriptors.  I obviously

            need to disable the CyU3PUsbSetDesc( ) calls in one of these routines,

            but I do not know which one.  I had intended to run the app and look at

            the bus traffic to figure this out, but the current problem prevents the

            PC from even asking for any descriptors.  I wouldn't think that these

            duplicated CyU3PUsbSetDesc( ) would cause the current problem, but I

            suppose I could be wrong.

             

             

            By the way, your email says I could reply on the forum, but I could find

            no way to add a reply to the forum post, so I am sending this email

            instead.  What do you have to click on to respond to a forum post?

             

             

             

            Best regards,

             

            Dr. Bob Miller

            Trace Systems, Inc.

            drbob@tracesystemsinc.com

            304-876-8711

            • 3. Re: How to fix bus speed negotiation failure?
              abhinavg_21

              Hi Bob,

               

              -- I could also connect a USB2 cable into the bottom part of the USB 3 connector on the FX3.

              Yes it's a good idea.

               

              -- I have attached a zip file containing the entire directory tree.

              Thanks I will look into it.

               

              --

              I wouldn't think that these duplicated CyU3PUsbSetDesc( ) would cause the current problem, but I suppose I could be wrong.

               

              I think this could be a problem. CyFxUsbHidApplnInit( ) and CyFxBulkSrcSinkApplnInit( ) has lot of common API calls like registering the setup call back, event callback, connectstate, setdescr etc.

              Instead of merging 2 firmwares better take HID firmware as base and add bulk endpoint in it. Also you can add extra setup call back cases for the bulk endpoint in the base HID firmware.

               

              Thanks & Regards
              Abhinav