07-19-2019 01:37 AM - edited 07-25-2019 12:15 AM
I'm trying to test a usb vendor-defined device with 2 bulk endpoints on zcu106 evaluation board.
Then I noticed that XUsbPsu_EpXferComplete() does not return the correct actual number of bytes transferred.
Simply debugging XUsbPsu_EpXferComplete() function which is endpoint handler in xusbpsu_endpoint.c as shown below.
You can see that TrbPtr->Size=1024 and Ept->BytesTxed=0.
Ept->BytesTxed indicates actual number of bytes transferred.
And TrbPtr->Size indicates the number of bytes to be transferred and decreases by the number of bytes actually sent/received.
However, TrbPtr->Size was never decreased.
I got a hint by looking at the following sentence in the link below.
"XUsbPsu struct being placed in an incorrect memory location with respect to its 256 byte alignment request. I've fixed that"
The TrbPtr->Size is a member of the XUsbPsu_Trb struct, and the address of instance of the XUsbPsu_Trb struct is written in DEPCMDPAR1 register.
The DEPCMDPAR1 register seems to require a 64bytes size aligned address by several tests.
Likewise, simply debugging,
You can see that the address of XUsbPsu->eps->EpTrb is 0x113140 that is aligned 64 bytes in size, but EpTrb and EpTrb are not 64 bytes size aligned address.
The source is trying to align the EpTrb array using ALIGNMENT_CACHELINE as below.
However, the elements of EpTrb array were not aligned to a size of 64 bytes as you can see above.
Since the elements of the EpTrb array only need to be aligned to 64 bytes, I simply added the padding bytes as shown below to make the XUsbPsu_Trb structure 64 bytes in size.
When debugging again, you can see the addresses of the elements of EpTrb array are aligned 64 bytes in size as shown below .
&EpTrb ==> 0x113280, &EpTrb ==> 0x1132c0, &EpTrb ==> 0x113300
All three are addresses aligned 64 byte in size.
You can also see that TrbPtr->size is decreased well and Ept->BytesTxed is printed well.
==> It shows that prepared 1024 bytes for transfer and 836 bytes were left, so 188 bytes were received.
Thanks for reading.
07-21-2019 07:16 PM
Thanks for sharing that vvilly! Point to the post and Mark it as Accepted Solution, to benefit other users.
09-23-2019 08:45 AM
I had the exact same problem and your solution fixed all my experienced issues. Thank you for the solution, hopefully Xilinx will fix this in their official bare-metal drivers.
09-26-2019 11:20 AM
10-14-2019 05:13 PM
A Change Request (CR-1046617) was submitted to reflect your input.
10-21-2019 12:51 PM
Thanks for sharing! This resolved my Tx and Rx DMA issues with the USB v1.5 BareMetal driver! Not sure why DMA for the baremetal USB mass storage example seems to work... (?)