You are here

Problems with USB interrupt endpoint IN | Cypress Semiconductor

Problems with USB interrupt endpoint IN

Summary: 1 Reply, Latest post by Madhu Sudhan on 31 Oct 2015 08:10 AM PDT
Verified Answers: 0
Last post
Log in to post new comments.
hwbits's picture
3 posts


I try to use interrupt endpoints IN to send data and debug messages to the host. After several tries I was able to receive some messages with Control Center. During my unsuccessful tests I discover several thing by using the following setup:

   - FX3 application = USBDebug example from Cypress homepage
   - Cypress Control Center as host software to poll interrupt endpoint
   - as hardware I used the Cypress FX3 Development Board and my one FX3 design.
   - to debug my software and I use Cypress SDK with a J-Link debugger

As result I made following observations:

  1. FX3 application will hang after a while when endpoint is not polled by host. It seems interrupt endpoint is not able to consume continuously data and flushing endpoint, when data are not polled by host. This behavior is mentioned in the API Guide!?
  2. Observation 1 can be speed up by decreasing ThreadSleep time and/or by increasing loop increments. And I tried to save time and modified both knobs immediately an run into problems.  
  3. When application hangs I receive error "INTERRUPT IN transfer failed with Error Code:997" Control Center
  4. It seems FX3 executes tx_thread_schedule () and has no reason to work on my task. Maybe FX3 is waiting for a resource ...?

As mentioned before I like to transmit debug messages through an interrupt endpoint IN, so I can not guarantee there is a host application polling and my application hang when I started testing my new feature. After several hours in investigating return codes, DMA objects and other stuff I found following  post "About DMA transfer in slave FIFO", which helped me.

Disabling FX3 automatic power management by calling CyU3PUsbLPMDisable () and removing CyU3PDebugLog () or CyU3PDebugPrint () function call. This means using CyU3PDebugLog () and CyU3PDebugPrint () in the same application result in problems.
With this modifications USBDebug application is running without problems. Polling data with Control Center is still failing after some reads.

So there are some questions left where I did not found an answer or have no idea how to go ahead:

  1. Can someone else confirm my observations?
  2. Has someone else similar problems with interrupt endpoints IN? I like to save time and not to run into each possible problem!
  3. Why is power management blocking my application or is the CyU3PUsbLPMDisable () function call only helping and not the root cause of my problem?
  4. What is the difference between CyU3PDebugLog () and CyU3PDebugPrint () both are sending messages through a consumer socket. Only CyU3PDebugLog () collects several messages till the buffer is full.
  5. Why is Control Center failing after some read when my application uses CyU3PDebugPrint () and failing after one read when I use CyU3PDebugLog ()?
  6. What means error code 997 in Control Center in detail?

Thanks for your help!


mady's picture
Cypress Employee
964 posts

1) So far we haven't tried using or heard anyone using DebugLog along with DebugPrint. But I hope there should be no issues in this.

2) No. But may be LPM could be a problem here

3) Power management does not block the Application. Only the data transfer would fail. Calling LPMDisable should fix this

4) To know how exactly they differ, please refer the Source code along with the SDK package.

5) i suspect the LPM.

6) 997 is a Microsoft defined error code meaning "Overlapped i/o operation in progress". Here it simply means that the transfer has timed out because of unavailability of data.


-Madhu Sudhan

Log in to post new comments.