USB Problem caused by Intel C-States

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
yvjec_3905651
Level 1
Level 1

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

0 Likes
1 Solution
yvjec_3905651
Level 1
Level 1

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

View solution in original post

0 Likes
4 Replies
Sananya_14
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

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

0 Likes

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

0 Likes

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

0 Likes
yvjec_3905651
Level 1
Level 1

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

0 Likes