This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
We have a problem with transfers of more then 4 linklistelements, if one of them has a longer sourcebuffer .. 1.5kb...
Are there any limits? I can send about 50 Buffers in a CAT_mode (all in one transfer) but it seems, with only one longer
datasource and/or different length on the listelements, we get errors up more then 4 Linklistelements - wrong length and
data on the 4th. part of the linktransfer.
This seems like a csl_bug or a problem with internal USB_DMA_channels? We get a wrong transferlength on the hostside
We are looking into this and will get back to you.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Vasantha K:
After 20 more ours of debugging, i figured out, that it could be a bug in the USB_engine (SIE) himself.
First step was debugging the work on the linklistbuffers - the "old" bug of the USB_csl, that the "transaction_done
flag is true, before the RLD/GO Interrupt on this endpoint has fired, (a particularly problematic issue in linklist transfers)
can be solved by an extra user Flag - "Do not use the function "IsTransactionDone" outside the Endpoint_Interrupt function!
This is an important message that should be in every TI USB_Forum
But this was not the problem here! (Rookie mistakes ...)
The first linklist will be completely processed ! The second does not overwrites or destroy the predessor.
With a USB_Hardwareanalyzer (Lecroy) we found out, that the next transaction (linklist + CAT) overtakes the previous.
-- that happens only in full speed, not im stepping (debug)
The second session was slightly harder. To get the errorsource, i store the DMA_structure of the affected channel on
every state (before and after the transfer and on the interrupt of this endpoint) in different Arrays and reviewed in particular
the stati of the go / red flags after a later breakpoint.
To get this brakpoint, I searched for a specific transfer sequence, which was typical before the bug.
But also in this level, nothing special was found.
The cpu never starts a transaction, before all stati on the DMA_channels was ok. (RLD/Go cleared)
But on the analyzer an the host we get the 5th "Header" - an event with data's in the 6th listelement, but
in the 6th transaction, we get the Header of the next transfer - in the 7th his data's - complete - one
linklistelemnet was overwritten, but it seems, that the USB_DMA hast comleted all transfers . the
overrun comes from the SIE?
Now,i have no idea, which USB_Register should debuged, to to find out what happened.
It is difficult to produce a comparable test code.
Here 3 USB devices (MSD, HID and a proprietary device) running parallel to a processor in full load.
Hope anyone can help.
In reply to Lars Dittmar:
In reply to Lalindra Jayatilleke:
not realy, the USB_Endgine on the 5509 is a little bit tricky, but also a little bit faulty.
The biggest Problem is the fact that you can not get reliable information about whether the data has been transferred. (really gone)
The transaction done flag is just a joke. (Never use that!)
We have more USB_Devices on this channel and a kernal_mode driver on the PC Side. The transfer in question consists of a linkslist
each with different long elements.
The best, but not errorless way is to generate the end of transfer information only from the endpoint_interrupt (events & USB_EVENT_EOT) on
the handler, make a semaphore to lock the link_list and to synchronize this and all over endpoints with PSOF. (events & USB_EVENT_PSOF)
That gives the best results, but not without transmission errors.
If an error occurs, an element of a link list is overwritten with a member of the Link List of the next transfers - exactly a complete
list item and then with the proper length and data of Elements from the next transfer. But the next linklist is not build until (EVENT_EOT!)
unquestionably! and of course, certainly not sent
That says even the Endpunkt_Interrupt says only that the data are in the -SIE- , not that they have been transferred and on a new t
ransfer the DAM overwrites a part of the -SIE-
This is a Bug, and i have no Idea, how to solve it, because there isn't any status to check this??
The question was, are there any limits for the DMA_Channels, but the complete linklist mostly are not longer the the 1536bytes of a slot of 1ms!
After a few weeks of debugging and timing analysis of the USB_CSL, the described error occurs when
sending concatenated lists only if the following conditions are met:
- > 3 list elements are sent
- The first list element always has 13 bytes in my case.
- The second list element has between 34 and 51 bytes (35-50 give error (save))
- The length of the list elements after that does not matter.
The error: The following list element is skipped, all afterwards transfer.
I start the transfer of the list with PSOF on EP3_IN. PSOF to SOF Time does not matter - always same errors.
I have tried various measurements.
First find out:
It helps to wait insight the USB_Ep3InEvHandler after USB_postTransaction (& usbEpObjIn3 ...
for 1ms or to lock all USB_Interrupts for 200us before the Transaction ((IRQ_disable (IRQ_EVT_USB);
But always more ... I have found that the following is enough:
If I immediately before transaction call a _USB_disableDmaIntrpt (USB0, & usbEpObjIn3)
And after> 200us _USB_enableDmaIntrpt (USB0, & usbEpObjIn3);
The error is gone for shorter linklists.
I think it is a bug in the USB_evDispatch () or deeper features, which only occurs when the
USB_DMA finishes with a list item in a certain time range. Then she loses the index to the next
and transfers the after next element. Think any part of the usb_csl isn't reentrant !!
If the linklistelements becomes longer, the blockade should also be longer (about 100us / 100byte).
The blockade of the interrupt only works up to a transmission length of about 1000 byte.
(About 1ms blockade) then the errors occur again.
It's just a workaround. It is better to find the cause.
Thank you for providing the workaround and feedback on this issue.
I will have to report this problem to the development team so that it can be root-caused/addressed in the next release.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.