- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear community members,
I have an issue regarding USB on XMC4500 and try to get any support.
In our application we are implementing 3 endpoints besides the default endpoint 0:
EP2 --> Bulk-IN
EP3 --> Bulk-OUT
EP4 --> Interrupt-IN
The XMC is configured as USB device in Buffer-DMA mode.
Currently we have an issue with the interrupt endpoint EP4. In our application we are transmitting 10 bytes data periodically (cycle time 5 seconds). The problem occurs when the 5th DATA packet is transmitted. The 5th DATA packet contains 5 bytes instead of 10 bytes. The first 4 bytes are correct, the last byte is wrong. Also there is a CRC error in this packet. We have detected these facts by using an USB tracer device, which was switched between the XMC and the USB host. The DMA buffer (DIEPDMA4 register) is configured correctly with the memory buffer which holds the data to transmit. Additionally the transfer size register (DIEPTSIZ4) is configured correctly, too:
DIEPTSIZ4.XferSize = 0xA
DIEPTSIZ4.PktCnt = 0x1
It is conspicuous that always the 5th packet causes this error (wrong packet length and CRC error) independent on the cycle time.
Furthermore we tested the behaviour with a packet length of 18 bytes instead of 10 bytes
DIEPTSIZ4.XferSize = 0x12
DIEPTSIZ4.PktCnt = 0x1
In this case just two packets were transmitted correctly. The 3rd packet contained 13 bytes instead of 18 bytes (again 5 byte less and again only the last byte was wrong).
Additionally we tried to send these packets via EP2 (Bulk-IN). This didn't cause any issues and all packets (more than 5 packets) were transmitted successfully.
Does anyone know, if there is any specific application requirement for Interrupt-IN endpoints which differs to Bulk-IN endpoints? Maybe there is any issue within the XMC4500 (I couldn't find any points in the current errata sheet V1.5).
Thanks!
Best regards,
autoUser
Solved! Go to Solution.
- Labels:
-
XMC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
DIEPTXFn is “Transmit FIFO Sie Register”, it only config the FIFO size, not definition the TX FIFO memory.
Here is a misunderstand.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Additional information:
- We tried the transmission with increased payload sizes. We have noticed that with payload size = 54 byte there is no valid packet transmitted. The first packet was invalid with DATA packet size = 53 byte.
- Normally according to USB the XMC uses all bytes within DATA packet for CRC checksum calculation. For the invalid packets the XMC uses all bytes except the last one within DATA packet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Additional information:
- We have replaced EP4 by another (e.g. EP1 and EP5) --> same issue
- During debugging we noticed that after clearing NAK bit (setting DIEPCTL4.CNAK) when transmitting the 5th packet the Transfer-Complete-Bit (DIEPINT4.XferCompl) is NOT set!!! I all the four transmissions before, the bit was set.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please upload your test project. We will let our USB expert to check this question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello @LinglingG_46 and thanks for your reply.
In the meanwhile I could detect the reason of the problem but don't understand it.
For that we have used the DAVE example project called "USBD_VCOM_APP_Example_XMC45" in Download of Example Projects for DAVE™ Apps.
In the reference manual of the XMC4500 we can see three registers to be configured for FIFO usage:
GRXFSIZ --> RxFIFO size
GNPTXFSIZ --> TxFIFO[0] size and start address
DIEPTXFn --> TxFIFO[n] size and start address (n = 1..6)
We also noticed that the value for the sizes in GNPTXFSIZ and DIEPTXFn have to be set in terms of 4 byte values (e.g. 16 means size = 64 byte). But during debugging we detected that the TxFIFO addresses differ from the description in the reference manual. Here two examples:
Example 1:
Register configuration:
Rx FIFO | |
GRXFSIZ | 00000040 |
Tx FIFO[0] | |
GNPTXFSIZ | 00100100 |
Tx FIFO[1..6] | |
DIEPTXF1 | 00100140 |
DIEPTXF2 | 00100180 |
DIEPTXF3 | 001001C0 |
DIEPTXF4 | 00100200 |
DIEPTXF5 | 00100240 |
DIEPTXF6 |
00100280 |
FIFO ranges (detected through debugging):
Rx FIFO Memory Range 0x50060000 - 0x500600FF
Tx FIFO[2] Memory Range 0x50060500 - 0x5006053F
Tx FIFO[4] Memory Range 0x50060600 - 0x5006063F
Example 2:
Register configuration:
Rx FIFO | |
GRXFSIZ | 00000040 |
Tx FIFO[0] | |
GNPTXFSIZ | 00100100 |
Tx FIFO[1..6] | |
DIEPTXF1 | 00100050 |
DIEPTXF2 | 00100060 |
DIEPTXF3 | 00100070 |
DIEPTXF4 | 00100080 |
DIEPTXF5 | 00100090 |
DIEPTXF6 | 001000A0 |
FIFO ranges (detected through debugging):
Rx FIFO Memory Range 0x50060000 - 0x500600FF
Tx FIFO[2] Memory Range 0x50060140 - 0x5006017F
Tx FIFO[4] Memory Range 0x50060180 - 0x500601BF
Expectation:
The base address for USB is 0x50040000. The starting address for Data FIFO RAM for debugging is 0x50060000. The starting address for RxFIFO is 0x50060000. According to chapter 16.14.1.1 in reference manual the...
starting address for TxFIFO[0] = size of RxFIFO
starting address for TxFIFO[n] = starting address TxFIFO[n-1] + size of TxFIFO[n-1]
As you can see in my examples the real Tx FIFO memory ranges are not equal to the addresses configured in the DIEPTXn registers.
Can you explain what is wrong here please?
Thanks!
Best regards,
autoUser
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
DIEPTXFn is “Transmit FIFO Sie Register”, it only config the FIFO size, not definition the TX FIFO memory.
Here is a misunderstand.