BIOSUSB hangs with fast packets

Peter,

I assume you might be on a earlier release of BIOSUSB package.  We released a new BIOSUSB stack with some fixes that are related to your issue, probably it is the same issue.  Could you update your BIOSUSB stack to the new version?

Appreciate you confirming that you are indeed able to develop a custom Function driver (which I have been recommending a lot to our customers) on top of the BIOSUSB stack.  Pl. note that we test the BIOSUSB stack with MSC and HID applications and may not have covered all the corner cases that a custom Function Driver might implement.  If you face such issues pl. do post the issue in the forum.

regards

swami

I am using version 01.10.02.

I do see that version 1.10.03 is in the process of being released, but no release notes exist.

I have noted that the .02 release fixed a bug in the HID example that I linked to, can I ask what the problem was? and what the fix was?

 Peter

Peter,

You can find all the BIOSUSB releases in the following link

http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSUSB/index.html

Peter Myerscough-Jackopson said:

I am using version 01.10.02.

I do see that version 1.10.03 is in the process of being released, but no release notes exist.

The latest release 01.10.03 is available at

http://bangsdowebsvr01.india.ti.com:8060/BIOSUSB/01_10_03_01/index_FDS.html

Regards,

Sundaram

the link is broken bangsdowebsvr01.india.ti.com does not resolve via DNS.

The above link is a mirrored link.  Try:

http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSUSB/index.html

if you go to that index the link links to the india.ti.com server,

Peter

Peter,

This problem is resolved now and the links have been set straight.

You can get the latest BIOSUSB package from the following link:

http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSUSB/01_10_03_01/index_FDS.html

which is also updated in the top level BIOSUSB page in

http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSUSB/index.html

Regards,

Sundaram

Thank you for fixing the links I have just downloaded BIOSUSB 1.10.03 . The problem  I have however persists. I have improved my code and found that part of the problem was that if the BIOSUSB stack does not have a read request pending when a message comes in it hangs the connection.

I have improved this, and now I seem unable now to break the ability for my code to stop reading from the BIOSUSB, I do however have a problem writing messages. As my first post stated I am sending very short messages to the DSP and echoing them back. However if I rapidly send messages from the host whilst also trying to rapidly send messages in response from the DSP, then my write callback occassionally is never called, not even with an error. Currently the flow of my program is to set up a write request, call core_send_data() and then block any further sends using a semaphore, that is unlocked in the callback. The call back then releases the semaphore and and assuming their was not an error allows the program to send the next message in the queue, or repeat the message if an error occured. Since the callback is not being triggered however my code blocks and never sends another message. I could work around this, but I am also unsure as to what the BIOSUSB is doing, and I have no knowledge of what sort of time out if any is appropriate on sending a message, because I would have no control to cancel such a message if such a timeout is reached,

Peter

Peter,

Peter Myerscough-Jackopson said:

As my first post stated I am sending very short messages to the DSP and echoing them back. However if I rapidly send messages from the host whilst also trying to rapidly send messages in response from the DSP, then my write callback occassionally is never called, not even with an error.

Can you try just sending some data from the DSP to the host instead of doing this loop-back? I am asking because there is no limitation from the BIOSUSB stack in writing out data. So your write callback must be called always.

I think this might be happening because of some problems in the reading side, what if a data is not read? So if you do a continuous write from the DSP, we can identify where the problem exactly is?

Regards,

Sundaram

Sundaram

Thank you for your response, we have been taking our time to make sure we are correctly identifying what is going on. As per your suggestion we have implemented a short message, from the Host to the DSP, which causes our application to send multiple packets from the DSP to the Host.

In our code we are only queueing one write transaction at a time and queuenig the next transaction on completion, either from the write transaction callback (if another packet is waiting) or from a separate lower priority thread when new packets are needing to be sent.

If we set our short message to send small packets(~1k) then occassionally the call back is not triggered. If however we enforce a small delay between queueing new transactions we are able to consistently queue send transactions and have our call back triggered, but this will obviously impact on our data rates, and we cannot be sure we have not simply reduced rather than eliminated the problem.

Regards,

Peter

Sundaram,

It has come to our attention that the Silicon Errata for the TMS320C6748 which is the chip we are using has an issue when transferring packets of different sizes, which is what we are doing, but in separate transactions. The section in the Errata of note is  "2.1.1 USB0: Generic RNDIS Usage Note". Now since we are not directly queueing data I am unsure if this is applicable, but since we are sending small packets of varying sizes it might be pertinent. Having said that this note would appear to apply to code inside the BIOSUSB stack, and not our code. I am also unsure if we are using RNDIS.

Regards,

Peter

Peter,

The silicon errata applies to the BIOSUSB stack and is effectively handled, so no impact to the applications on top.  Usage of RNDIS modes are taken care within the BIOSUSB stack.

regards

swami

Swami

Thanks for a rapid response,  that helpfully rules out one cause, but still leaves us with the problem at hand,

Peter

Dear all,

We have just tried turning the DMA off for the DSP-to-host transfers by setting the BIOSUSB parameter dma_option in the pipe_desc_t  from DCD_REQUIRED_DMA to DCD_NO_DMA. The callbacks now work as expected. This does reduce the data rate unacceptably though.

Hoping this information could help,

Regards,

Peter

The above post was marked as an acceptible answer where it isn't! the speed reduction between DMA and no DMA is unacceptable and so this is not a solution.In that the only aspect being changed is whether Jungo uses or does not use DMA for collecting the data for the DSP to Host transmissions. I would suggest that there is a race condition occuring that is either dependent upon the speed at which the data is being transmitted or the use of the DMA, either way not using DMA slows down the transmission of data over the USB to below 4Mbytes/second or 32Mbit/s which given that the bus can operate at a theoretical 480 Mbit/s / 60Mbyte/s or more realistic 30Mbyte/s. We have seen speeds of 8 to 10Mbyte/s using DMA, but then we see the afore mentioned problem whereby our send request callback is not triggered. We eventually are looking for faster speeds, but stability is most important,

Peter

Peter

If you are using the latest biosusb package (1.10.03.01),  Let me know what is configuration parameter passed for PSP_musbEpTrafficConfig() in usbInit( ) function in Please  bios_sample_main.c.

In device mode there two configurations DMA, whether device uses short-pkt or non-short-pkt only (usbdevmsc kind of application). Please check the DMA configuration used in usb_Init of sample main application in biosusb package.

You can the following configuration.

 /*
 * below are the request configuration for typical application
 * application     is_req_size_same is_req_shortpkt
 * usbdevmsc application    0    0
 * usb_cdc/rndis application  1    1
 *
 */
 ep_cfg.is_tx = 0;
 ep_cfg.is_req_size_same = 1;
 ep_cfg.is_req_shortpkt = 1;
 

Regards

Ravi B

Ravi

Thank you for pointing me at that code, I had not seen those additional aspects that needed calling to set up the USB and looking at the examples not all of them have calls to these functions. The example code you pointed me at is below, and I have a few questions :

-------------   
/*
 * below are the request configuration for typical application
 * application                 is_req_size_same    is_req_shortpkt
 * usbdevmsc application             0                0
 * usb_cdc/rndis application        1                1
 *
 */
    ep_cfg.is_tx = 0;
    ep_cfg.is_req_size_same = 0;
    ep_cfg.is_req_shortpkt = 0;
    for (i=1; i<=4; ++i)
    {
        ep_cfg.epnum = i;
        PSP_musbEpTrafficConfig(&ep_cfg);
        PSP_musbEpTrafficConfig(&ep_cfg);
        PSP_musbEpTrafficConfig(&ep_cfg);
        PSP_musbEpTrafficConfig(&ep_cfg);
    }

---------

1)  PSP_musbEpTrafficConfig(&ep_cfg); is called 4 times! I assume this is a mistake, unless you respond otherwise

2) I have an endpoint that is both for transmission and reception, I think I will need to setup the EpTrafficConfig for both directions, is it correct to call PSP_musbEpTrafficConfig(&ep_cfg); with is_tx equal to 0 and 1 consecutively or am I not interpretting this code correctly.

3) the is_req_size_same field is advised to be 1 for usb_cdc applications, why is this? I am wanting to send data of varying lenghts across my usb CDC ACM transport, should I be setting it to 1 or 0.

4) similarly the is_req_shortpkt is set to 1, what does this do? I have found that I need to send a zero length packet to end a transaction on Windows, and have built that into my USB code. Is that what this option is doing for me or does it mean something else?

5) is there any further documentation for the USB that I am missing, the two headers csl_usb_otg.h and csl_usb_ohci.h are both in the psp and yet they are not referenced or described anywhere in the PSP's documentation.

Thanks

Peter