CY3014 stop working after a while

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

cross mob
lich_4062331
Level 1
Level 1
10 replies posted 5 replies posted First reply posted

Hi eyeryone:

     i am working with cy3014 Some time,with default driver and AN65974. In AN65974, I have added iic controller to achieve my peripheral equipment control. I use the (control center) and (streamer) for testing.after a while of testing,it has been stopped. i did not know what have  happened,but i have a way to solve this problem,

     (1)Send command to FPGA to stop generating data,

     (2)reset x81.

     after this,i can work normally again。

     Please give me some thoughts on this phenomenon,thank you!

0 Likes
1 Solution

Hello,

If Watermark value of 2 is used in the firmware (16-bit data bus), then the FPGA must be able to write 2 data words after the assertion of Flag-B. After 5 cycles of assertion of Flag B, Flag A needs to be asserted (pulled low by the FX3 firmware). Is this condition is being met?

I see that the SLWR and Flag A is de-asserted. Please make sure that the entire DMA buffer is filled, i.e. SLWR is being asserted till 2 more data words are written after the assertion of Flag B. If this is not satisfied, then the DMA buffer is not filled and not committed to the USB side. This may be the cause for the issue.

Please refer to the Figure 13. in AN65974 for the waveform.

You can use a logic analyzer to probe the signals on the GPIF side and check if the SLWR is asserted only after completely filling the DMA buffer, else there will be no buffer committed to the USB side.

To check if the issue is from the firmware, you can continuously assert (pulled low) the SLCS, SLWR signal on the GPIF side, and stream IN the data using the streamer application.

If possible, can you please connect a Serial device to the UART lines of the FX3 to get the debug prints?

Thanks,

Yatheesh

View solution in original post

15 Replies
lich_4062331
Level 1
Level 1
10 replies posted 5 replies posted First reply posted

pastedImage_0.png

when it stops, it looks like this.

0 Likes

Hello,

Can you please let me know if you are using the super speed explorer kit or a custom board.  If you are using a custom board, do you have a serial bridge connected to the UART lines of the FX3?

In the traces can you please point me to the instance where the streaming stops. Is there an IN request sent from the host side and what is the URB request status returned in that transaction?

Thanks,

Yatheesh

I am very excited to receive your reply. It is my own circuit board and there is no serial port. This problem only happens occasionally. In addition to grabbing the received data on the bus huond, there is currently no other debugging method. Are there any restrictions on our default driver?

0 Likes

Hello,

Is the SLWR and SLCS line on the FX3 asserted always by the FPGA?

Please try the below,

When the streamer stops streaming the Data from the FX3. Close the streamer, open the control center and do an IN transfer on the respective endpoint.

Let me know the if you can receive any data in the control center.

You can try using a software analyzer like the Wireshark USBpcap capture method and check the last In transfer request status from the HOST side.

An example capture:

pastedImage_0.png

Thanks,

Yatheesh

thanks for your reply!

When it works normally, it should be like this.

pastedImage_0.png

When it stops, it  sends a host, no data returns.

pastedImage_1.png

Then send URB_FUNCTION_ABORT_PIPE.

In control center,it looks like this,

pastedImage_2.png

what could be the problem?what shoud i do next?

look forward to your letter!

0 Likes

Hello,

The URB_FUNCTION_ABORT_PIPE is due to unavailability of data from the FX3 when the Bulk IN request is sent from the host.

Please make sure that the data is available from the GPIF side and is committed to the USB socket.

If you are using a manual channel then you can check the availability of data using vendor commands.

Declare a global variable and initialize the value as 0 in the firmware. Increment the variable on every producer event and decrement the same on a consumer event.

You can read the variable through a vendor command. If the value of the variable is zero when read, then there is no buffer data available to be read by the host from the endpoint. 

Please check the same when the streaming stops.

Thanks,

Yatheesh

Thank you for your reply!

The default project in AN65974,

In the cyfxslfifosync.h file,

pastedImage_0.png

In my test, when the MANUAL mode was selected, the data of the last packet was 731604B, but the reception was always incomplete.

pastedImage_1.png

And in this mode, the data rate cannot reach the transmission rate in the provided SF_streamIN.img. However, during multiple tests, there was no stuck situation.

What I want to know is, what is the difference between the source file of SF_streamIN.img in the template and the source file provided in the routine?

Looking forward to your reply!

Best wishes!

0 Likes

Sorry, I ignored a question. In MANUAL mode, the data is already incomplete. Each frame of data is 46 bulk, but now only 38 can be received, and the 38th is incomplete.

0 Likes

Hello,

Since you are using AN65974 firmware, the incomplete packets is may be due to the assertion of PKTEND signal form the FPGA, where the FX3 state machine treats the packet as a short packet and commits it to the USB side.

Please probe the control signals (SLWR, SLCS, PKTEND) on the GPIF interface to confirm this.

Also, you can refer to Figure 4. Synchronous Slave FIFO Write Sequence from AN65974 for a better understanding.

The reason for the halt of data streaming in the streamer application is probably due to the improper data length request form the host application. When this happens, you will need to reset the respective Endpoint.

Please select the IN endpoint from the control center and reset the respective pipe using the "Reset Pipe" button in the control center

I have tried implementing the application note AN65974 on Explorer kit with SLRD, SLCS left asserted. I do not see any failures or other issues.

pastedImage_4.png

Thanks,

Yatheesh

Thank you very much for your patience!

We had a holiday a few days ago, and returned your information so late. After so many days of testing, I borrowed a board containing the cy3014 chip in other projects to test. In the case of the same firmware program and the same fpga program, the problem of sudden data stop will not occur when receiving data for a long time. I think this may be the first hardware problem of the board.

Now I have a new problem. When the amount of data is relatively large, such as when the interface rate reaches 350MB, if my queue is opened less, the data will be incomplete. For example, in your last reply to me, you opened 16 queues. If I only need to open 4 queues for a frame of data, and then return the reception success flag, the application software takes the data from the 4 queues in the buffer. When using 4 queues to receive such high-rate data, the data in the individual queues It is incomplete, which means that I need to open 16 or 32 queues to ensure the correctness of the function.

What should I do to return the reception success flag every time I receive the correct length of data?

Looking forward to your reply!

Best wishes!

0 Likes

Sorry, I thought it was a problem with the board, but it also stopped on another board.

I used FPGA debug to grab the signal and found that when this problem occurs, FLAGA will be pulled high, but FLAGB is always low, may it be a firmware problem? If it is a firmware issue, how should I debug it?

pastedImage_0.png

pastedImage_1.png

pastedImage_2.png

0 Likes

Hello,

If Watermark value of 2 is used in the firmware (16-bit data bus), then the FPGA must be able to write 2 data words after the assertion of Flag-B. After 5 cycles of assertion of Flag B, Flag A needs to be asserted (pulled low by the FX3 firmware). Is this condition is being met?

I see that the SLWR and Flag A is de-asserted. Please make sure that the entire DMA buffer is filled, i.e. SLWR is being asserted till 2 more data words are written after the assertion of Flag B. If this is not satisfied, then the DMA buffer is not filled and not committed to the USB side. This may be the cause for the issue.

Please refer to the Figure 13. in AN65974 for the waveform.

You can use a logic analyzer to probe the signals on the GPIF side and check if the SLWR is asserted only after completely filling the DMA buffer, else there will be no buffer committed to the USB side.

To check if the issue is from the firmware, you can continuously assert (pulled low) the SLCS, SLWR signal on the GPIF side, and stream IN the data using the streamer application.

If possible, can you please connect a Serial device to the UART lines of the FX3 to get the debug prints?

Thanks,

Yatheesh

Thank you very much for your reply!

I have a question, that is, when performing a soft reset on cy3014, the waiting time is 5s, which is too long for me. Is there any other way to make the cy3014 quickly reset the input channel(bulk in 0x81) when a fault occurs?

pastedImage_0.png

pastedImage_1.png

Looking forward to your reply!

thank!

0 Likes

Hello,

If the pipe is reset from the host side, the delay is expected.

For a better solution, you can try sending a vendor command to the firmware when a transfer fails to reset the respective DMA channel using the CyU3PDmaChannelReset API. This may be a faster solution.

Thanks,

Yatheesh

0 Likes
lich_4062331
Level 1
Level 1
10 replies posted 5 replies posted First reply posted

I am very excited to receive your reply. It is my own circuit board and there is no serial port. This problem only happens occasionally. In addition to grabbing the received data on the bus huond, there is currently no other debugging method. Are there any restrictions on our default driver?

0 Likes