CY3014 Xfer to FPGA failed ,Part 2

[Stevenlm57]

Dear Yatheesh,

Sorry to bother you again.

After the last /RD signal problem was solved, no more underrun error.

But recently, all system combined test, I received error "No error : 18" from CY3014 uart port ,then, Xfer to FPGA failed.

Please kindly advise what is "No error : 18" ?

BR

Steven.

[Rashi_Vatsa]

Hello Steven,

From the Wireshark traces, it seems that the application works fine when data is being sent from Host PC to FX3 using Streamer host app for both 16 bits and 32 bits.

So the failure is seen only when GPIF is configured for 32 bits and custom host application is used instead of Streamer application to send data to FX3.

Please confirm when changing the GPIF bus width to 32 bits the bus width is also changed in the GPIF State machine and the header file is build again and included in the project.

Please program Fx3 with the attached firmware (configured for GPIF 32 bits ) and share both UART debug prints and USB traces (Wireshark)

From your last response the problem doesn't seem to be in the hardware.

[Stevenlm57]

Dear Rashi,

By the way,I test gpif32bits at DVK BOARD(purchased from market,not Cypress original) under same conditions(fast switching data pattern),also showed the same problem

BR

[Stevenlm57]

Dear Rashi,

1.As I said many times,at gpif32bits mode,both Streamer(send fixed pattern) and our host custom ap(send long++) all works fine. 
2.Failure only happens at our host custom ap sending 0x55555555-0xaaaaaaaa pattern under gpif32bits. 
Stream did not send such pattern,so ,could not be compared in this way. 
I ever tried control center to send file(0x55555555-0xaaaaaaaa repeated) 16384 bytes, also failed at 2nd or 3rd time. 
The sending contents is the key-point. 

3.”when changing the GPIF bus width to 32 bits the bus width is also changed in the GPIF State machine and the header file is build again and included in the project.”

=>In GPIF editor,I change bus width at the first page only,then build it. And all rest procedures you mentioned were done except state machine page ,do I have to do anything in that page ?

In fact ,UNDER GPIF32bit mode,all 32bits data are transferred correctly and so our printer printout also correct,except warm reset issue. 
I will try your firmware and feedback. 
BR

[Stevenlm57]

Dear Rashi,

I programmed FX3 32 bits with your provided firmware,it showed the same result as I had.

Please refer to the attached log files.

Custom AP : generate long++  data pattern, another one is 0x55555555-0xaaaaaaaa repeated.

In the attached log, custom-ap-long++  =  normal without any problem.

customer-ap-55-aa-failed : problem occurred immediately.(please be advised the top 3/5 logs are from long++,please focus at bottom parts).

Please give a hint if you find anything.

Thanks.

BR

[Rashi_Vatsa · Accepted solution]

Hello Steven,

It seems that in your case the XACT_ERROR, which is causing warm reset, occurs when data which high transition like 0x5555 and 0x AAAA is sent to the FX3.

To narrow down the problem, please try the following

Test 1) Modify the streamer application to send only 0x55 instead of 0xEF.

Please back up the default streamer application and do the above changes after copying the streamer to a new location.

Test 2) As you confirmed earlier that SDK 1.3.4 is being used in your application try using the library attached with this thread Solved: Re: FX3 Superspeed communication fails on link err... - Cypress Developer Community   and try using the modified streamer app (sending 0x55) or the custom app sending 0x55

Note: Please make a copy of the original library before placing the new one.

Also, let me know if the if you have hardware USB analyzer like Lecroy.

[Stevenlm57]

Dear Rashi,

Yes,your understanding for my case is correct.

1.Our software engineer ran Visual 2013 to compile the streamer,successful,but could not run.

Can you please directly provide a streamer with 0x55 as you said ?

2.I have download the modified LIB and will try soon.

And sorry,I have no USB analyzer.

Thanks.

BR

[Stevenlm57]

Dear Rashi,

I just tried the new LIB and still failed.

At present ,16 bits is working fine for my case right now and its bandwidth is good enough for my project.

The problem casued by 32bits high transition spent too much time to troubleshooting it.

I think I have to give it up and using 16bits now.

Thank you very much for your kindly help always.

BR