4 Replies Latest reply on May 15, 2019 11:24 PM by yves.jegge_3905651

    USB Problem caused by Intel C-States

    yves.jegge_3905651

      Hey there,

       

      Since more than ten years were using a CY7C68013 USB without any big problems. However, we recently noticed customer increasing complaining about several "USB-Connection Failures". Therefore, we now intensely are trying to fix the issues. I updated the Cypress driver to the newest version and removed several issues in our Code. However also noticed that some errors were CPU load depended. When having a low CPU loads USB data traffic get damaged since we only have a small buffer on our FPGA. When increasing the CPU load with a CPU benchmarking tool no data loss is visible. After some research I found the following Discussions:

      FX3 bulk transfer unreliable on Windows 10

      Cyusb3 v1.2.3.20 load depending data lost issue?

      FX3 Bulk Transfer gaps on fast Windows 10 laptops

      Thereafter I disable the C-States in the BIOS setting and no data loss was visible. Since several thousand installed were made on different computers, disable de C state in the BIOS is not an option. Neither adding a dummy thread to our application. Therefore, I may have to add a dummy endpoint as mentioned in the discussion. Or is there any other solution for that problem?

       

      Regards

      Yves

        • 1. Re: USB Problem caused by Intel C-States
          SananyaM_56

          Hello Yves,

           

          Could you please let us know why adding a dummy thread or piece of code will not be possible? Adding dummy endpoint will require some data transfers on the endpoint to prevent idle state which will take up some USB bandwidth as well.

           

          Best Regards,

          Sananya

          • 2. Re: USB Problem caused by Intel C-States
            yves.jegge_3905651

            Hello Sananya,

             

            We use the CY7C68013 USB in our medical device for over ten years. The Business Environment is quite conservative and thus the computer is mostly quite restricted or old. The Application was built in java and communicates via C++ DLL with the device. In our application we are performing some extensive calculations (Image processing, OCT filtering etc.) so we need the CPU Power. Deepening on the application up to 30 Java thread were started. I only could eliminate the error to 100% when I added the java thread (simple counter) without sleep/wait. Thus the CPU load was around 60-90% constantly. In older installation that may be an issue. Moreover, there is quite some installation with notebooks. How should I legitimate a quite constant CPU load from 60-90%? Moreover, our application is mostly used with a 3th party ERP system which also requires some CPU load.

             

            However, your objection is justifiable. I think the USB Bandwidth would not be an issue. However to change the firmware on the CY7C68013, since no over the air firmware update is possible (the logic of the device is on the FPGA/Java Application)

             

            Regards

            Yves

            • 3. Re: USB Problem caused by Intel C-States
              SananyaM_56

              Hello Yves,

               

              Based on the explanation, since you are able to maintain the CPU load to 60-90% after adding the thread, maybe for older installations you could provide an update to the new application.

              To make sure the CPU load is constantly within 60-90%, you could check the minimum load that will be required while running the application in Visual Studio in Debug mode.

              Please refer to an article on the same issue faced by other USB devices if you would like more details.

               

              Best Regards,

              Sananya

              • 4. Re: USB Problem caused by Intel C-States
                yves.jegge_3905651

                Hello Sananya,

                Thanks for the response.The IDS document was helpful to better understand my problem. However, it seems that i could found a adequate solution. With the Windows API powersetting.h header | Microsoft Docs I can fix the issue:

                 

                PowerGetActiveScheme(NULL, &scheme);

                PowerWriteACValueIndex(NULL, scheme, &GUID_PROCESSOR_SETTINGS_SUBGROUP,&GUID_PROCESSOR_IDLE_DISABLE, AcValueIndex);

                status = PowerSetActiveScheme(NULL, scheme);

                 

                This API seems to open a dummy thread with the lowest priority. Thus other applications were not affected.

                Regards

                Yves