any limits on linklists and / or datasize on USB 5509?

Hi

We are looking into this and will get back to you.

Regards

 Vasanth

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.

Hi Lars,
Could you please clarify your question? Its a bit difficult to pick out the actual problem from your description above. Is it still the wrong transfer length on the hostside?

Lali

Hi Lali

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!

Lars

Lars,
I'm checking on this with some folks with better USB knowledge. Will post back here with any feedback. Thanks.

Lali

Hi Lali, the USB_DMA overwrite or ignore exactly one part of the linklist on transfer to the see. This Bug depends on the length of the listelements.

I have a testsequence with 4 elements. 13 - 20 - 13- 10 - bytes - 56 at all. If the second linklistelement ist 22 - 58 byte at all, the thirth don't comes out. - the transfer ist 13+22+10. - 45bytes

This doesnt depand on the data himself or the memorylocation of the data! If we make it with 2 transfers (13-22) - (13-10) all ist ok.
I have checked the linklist after the transfer - no changes.

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.

Lali,
my workaround is not realy a solution, because the error comes back on linklists with more then 1ms (1023byte) But exactly for this one sends linklists! The Lib is from 2005!!! Lots of bugs and no update for 12 years! There is no solution to wait for an update! How long should I wait? Ten years? No! We have to solve the problem. It can not be so difficult to generate and send a link list with my parameters.
BR Lars

Lali,
4 month no solution? Can you ask the development team?