CYUSB3011 acting like the CYUSB3013

[KePa_4784036]

Hi Infineon team,

I had a weird behavior with my USB3 communication in my application so I went back into the Cypress code to figure out the issue and recheck everything that was implemented. We are using the CYUSB3011-BZXC chip and we use an FPGA->GPIF 16-bit->DMA->PC link design.

While checking the code, I figured out that it was based on the "slfifosync" example but was not corrected with the CYMEM_256K define which, as I understand, would change the way the memory is written with lower values for the DMA buffers, program memory, etc. It seems that we also used an old version of the "cyfxtx.c" file and we also used the default "fx3.ld" linker file (linked to this post). Since we didn't think too far about it while using the example, we went all-in and pushed the DMA buffer size to whatever felt right with our FPGA. We have 2 DMA channels; 1 U2P auto channel with size = 1024, count = 2 and 1 P2U auto channel with size = 32768, count = 4. We use GPIF on one side of the DMA and a USB endpoint on the other side.

I also followed this article KBA218339 to understand more about it. This link was also helpful to understand our limitations: Increasing-Byte-Transfer-CYUSB3011 . We do use the "CyU3PUsbStart" function which would add 1KB to DMA buffer space. We don't use the "CyU3PDebugInit" function. 

From my understanding of it, with our setup, it shouldn't work. But what's weird about it is that everything is working fine with our communication (minus the bug I have which might be FPGA or software side) and no compilation/programming error when using the "Control Center" packaged with EZ-USB FX3 SDK. We also were able to program the Cypress using a 144KB image file (.img) even though the code area for CYUSB3011 is only 128KB.

I'm a little confused on the reason of why it's working right now. It doesn't make sense. Am I in the wrong in my findings? Is there something I am missing in my researches? If you could path me with your thoughts it could help me a lot.

Thank you and have a nice day,

Keven

[Ajeethkumar_P]

Hello,

Please share the complete project you are using for CYUSB3011-BZXC. Please also share the UART debug logs while the code is running.
Eclipse compilation error will not happen because the compilation and linking will happen based on the linker script and based on that Image will be generated.
Control center programming will be succeeded as Buffer Area Memory is out of bounds and hence your program will fail only on run time.

Please verify if you are using CYUSB3011-BZXC silicon.

Thanks,
Ajeeth

[KePa_4784036]

Hi Ajeethkumar,

I will join the project. For the UART debug logs, we don't have them in our design. Understood for compilation and programming. 

Thanks,

Keven

[Ajeethkumar_P]

Hi,

If your project is private, please create a tech support case at mycases.infineon.com.

Thanks,
Ajeeth

[KePa_4784036]

Hi,

I edited my post with the project joined.

Keven

[Ajeethkumar_P]

Hi,

Can you verify if you are using CYUSB3011-BZXC silicon?
Please add the picture of the silicon here so that we can confirm the silicon you are using.

Thanks,
Ajeeth

[KePa_4784036]

 

[Ajeethkumar_P]

Hi,

Is the device properly being enumerated and working as expected with the Wrong linker script?

Thanks,
Ajeeth

[KePa_4784036]

Hi,

Yes, the device is enumerated, I can open it, send/receive data from endpoints, send control transfers. 

Keven

[Ajeethkumar_P]

Hi,

Can you try using the latest "cyfxtx.c" and check if you can reproduce this?

Can you share the *.map file with us?

Thanks,
Ajeeth

[KePa_4784036]

Hi, 

I tried the latest "cyfxtx.c" and I also used the right linker file (fx3_256k.ld). By doing so, without modifying my code, things were not working. I followed KBA218339 and rewrote a bit of the linker file to have the right amount of space for program size. I reduced DMA buffer size and count to be in the right under 32KB of range. Now things are working as it was before, but with (I think) the correct semantics.

I will link the .map file of my release build with the code I linked before in this thread.

Just to follow your progress, do you have any information why it is working with the wrong memory setup? I feel like I might be going over the system RAM and into the unused part?

Thank you,

Keven

[Ajeethkumar_P]

Hi Keven,

In the latest cyfxtx.c, Memory corruption checks are enabled which will check for Start and End signatures for each Memory block allocated for DMA buffers. When you say things were not working with the latest cyfxtx.c, these signatures might be overwritten.

Can you share your project with old configurations so that we can try to reproduce it from our end?
If your project if confidential, please create a case in mycases.infineon.com.

Thanks,
Ajeeth

[KePa_4784036]

Hi,

I already shared it. Look at my 2nd message.

Keven 

[Ajeethkumar_P · Accepted solution]

Hi,

I tried to recreate the issue with your cyfxtx.c. I could see that Main appication thread got stuck, but enueration was successful(due to the handling in interuppt handler) when I build with "fx3_512k.ld". So, the device functionality is affected with "fx3_512k.ld" when you have 256KB RAM. In addition to that, memory corruption would happen(as this is not properly handled in old cyfxtx.c).

I would recommend you to use the latest code example (with latest cyfxtx.c).

Thanks,
Ajeeth

[KePa_4784036]

Hi, 

Thank you for your response. We didn't use the main thread that much in our application (no control transfers sent) to communicate directly with the chip which could explain why we didn't see any problem. Were you able to send/receive some data through the DMA channels with the fx3_512k.ld + 256KB RAM?

Have a nice day,
Keven

[Ajeethkumar_P]

Hi Keven,

No, we didn't test DMA transfers. But, if you do DMA transfers, as the buffer area address got corrupted with old cyfxtx.c, you won't be able to get valid data.

Please use the latest "cyfxtx.c" with the 256k Linker script.

Thanks,
Ajeeth