• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 98 subscribers
  • Views 685 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Problem with OTG on the CE 6.14 BSP

JemiahAitch
Intellectual 290 points
Other Parts Discussed in Thread: TPS65950, OMAP3530

I've got a problem using USB OTG with an FTDI usb-serial converter. I'm using the FTDI supplied DLL with the 2.x BSP (from BSquare) running on a board with the OMAP3530 and the TPS65950.  The OTG connection works great for mass storage, keyboard and mouse. However when we connect an FTDI usb-serial converter, an application that opens the corresponding serial port can only transmit data but not receive it. When any data is sent to the board, the OTG host driver has a problem which we haven't been able to isolate yet.

So far all we've been able to discover so far is that the OTG interrupt may be continuously firing and that the driver seems to think it's continuously receiving  2 bytes of data. When it does actually get a byte of real data it can't process it because it beleives that it doesn't have enough buffer space. It throws the error message found in chw.cpp:2476, "Warning!!! Not enough buffer size!!!".

If anyone has any insight on this I can provide more information.

Thank you,
Jemiah

.

 

 

 

  • 0
    TI__Genius 9185 points

    I'm not sure what 2.x BSP is. The releases from bSquare have been traditionally numbered as BSP 6.xx.yy. Latest one is BSP 6.14.01.

    But to get back to your point, USB short pkt issue is a known issue and a fix for this is coming in the BSP 6.15.00 release slated for early October. 

     

  • 0 in reply to Jatin Jain
    Intellectual 290 points

    I'm sorry. I got my version numbers crossed. We're using the 6.14.01 BSP.  I looked through the release notes for 6.14.01 and also in the TI bug database

    (https://cqweb.ext.ti.com/cqweb/main?command=GenerateMainFrame&service=CQ&schema=SDO-Web&contextid=SDOWP&queryID=34371711&username=readonly&password=readonly)


    I didn't see a reference to a short packet issue. We did find a data alignment issue in the USB host code, musb:musbhcd:musbmhdrc:chw.cpp that may be what you're refering too.  Could you tell me the issue id? 

     

    Thank you very much,

    Jemiah

    .

     

     

  • 0 in reply to JemiahAitch
    TI__Genius 9185 points

    The bug ID is SDOCM00069457. It is not filed as a short pkt issue. The issue was initially found as delay in detecting certain devices on the OTG port while the same devices were detected fast on the EHCI port. Then we heard issues similar to what you mentioned in your post. And when it was debugged it was found that the issue was related to short pkts (< 4 bytes) not being handled properly. The fix is in ctd.cpp and chw.cpp. 

    Can you provide details on the data alignment issue you mention above. Maybe we are referring to the same thing.

     

  • 0 in reply to Jatin Jain
    Intellectual 290 points

    Ok I see it now. The web DB had a little more info but nothing about the extended effects you describe. Can you tell me more about those? We may be talking about the same thing. The data alignment issue we found was in CHW::ReadFIFO:

            // First read the 32-bits of data if any
            for (i = 0; i < total; i++)
            {
                *pData = INREG32(&pOTG->pUsbGenRegs->fifo[csrIndex]);
                dwRead = dwRead+4;
                pData++;
            }   

            // Now look at remaining and read the rest
            if (remain & 0x2) // either 2 or 3
            {
                USHORT *p16 = (USHORT *)pData;
                *p16 = INREG16(&pOTG->pUsbGenRegs->fifo[csrIndex]);
                dwRead = dwRead+2;
                p16++;  // Since 2-bytes, increment 1 only, not dwRead
                pData = (DWORD *)p16;
                remain = remain - 2;
            }

            if (remain & 0x1) // 1 byte left to read
            {
                UCHAR *pByte = (UCHAR *)pData;
                *pByte = INREG8(&pOTG->pUsbGenRegs->fifo[csrIndex]);
                dwRead++;           
            }

    We found that it'll have trouble with processing a single byte depending on the value of pData at the time of reception.  Is that what you were seeing?  I have two separate engineers looking at at this who  wrote their own fix for the issue.  You said that there would be a fix coming out in the next release in early October. Do you have access to any pre-release code? If so, and it can be shared I'd love to see it. I believe my company has confidentiality agreements in place with BSquare and I know we have them in place with TI if that's an issue. Can you get my email address from my profile?  Anything you can share would be a great help.


    Thanks,

    Jemiah Aitch

    LogicPD

    .

  • 0 in reply to JemiahAitch
    TI__Genius 9185 points

    Even though the issue seems to do with number of bytes, I don't think anyone has reported or seen an alignment issue with the ptr (in the code you indicated). The fix that I was talking about is in a different function. But your description of the issue is similar to the ones we have seen from couple of other customer. So it is worth a try. Maybe we have an additional issue.

    I don't have access to your email id. Also I cannot put the files in the post. Can you contact bSquare and get files from them. Worst case I can just post a patch here.

  • 0 in reply to Jatin Jain
    TI__Genius 9185 points

    Find a patch file attached (created using diff similar to that used in Linux). Please note that the patch is on top of the unmodified BSP 6.14.01 version of ctd.cpp and chw.cpp.

     

    usb_otg_short_pkt.patch
  • 0 in reply to Jatin Jain
    Intellectual 290 points

    Thanks so much for the patch. We'll test this in the AM and let you know what we find. Thanks for providing so much support on this issue. We really appreciate it.

     

    Jemiah

    .

     

  • 0 in reply to JemiahAitch
    Intellectual 290 points

    Our customer did some initial testing late on Friday and it looks great so far. They're using a OTG USB-Serial dongle to talk to a sat-radio so they're going to do some additional profiling of the connection.  There was a different issue where the OTG devices would seem to drop off and then reconnect at unexpected times. Perhaps this patch will resolve that too.

    Thanks very much,

    Jemiah

    .