• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 317 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.

C6747 USB delay

Lopi
Intellectual 470 points

Hi all,

I am having a problem with the C6747 USB interface.  I am using the BIOSUSB_01_10_03 device driver from Jungo to interface my Spectrum Digital EVM to a PC running XP.  On the PC the device shows up as a removable drive and the Windows usbstor.sys driver gets loaded.  I have a custom application on the PC that requests data every 300ms from the device using a ReadFile.  Most of the time this works fine and the data (64kB) arrives within a few ms, but occasionally (maybe once every few minutes) there is a long delay of 10 seconds between the downloads.  I've tried running USB tracing software on the PC and I can see that I get a STATUS_CANCELLED returned from one of the IRPs.  On the DSP side I see that the functions MSG_cancelLun, MSG_closeLun, MSG_openLun and MSG_getLunDetails in msd_blkmedia_glue.c get called.  Has anyone else seen this behavior?  I'm tempted to write the USB firmware myself so that at least I can debug things, but this seems like such a daunting task.

Thanks for any help,

Lori

  • 0
    TI__Expert 7435 points

    Lori,

    I assume that you are using the MSC app on the DSP side (that gets packaged with the BIOSUSB package) - unmodified.

    The messages that you mention - closelun, openlun etc. might mean that the device is getting reset.  Do you see any resets on the usb bus (if you are using a usb bus analyzer).

    When you mention that you are reading 64KB every 300ms how do you know that the data is current.  Pl. note that local filesystem (from DSP) and PC cannot access the same storage partition (that is exposed over usb) at the same time.  Their access has to be exclusive.  If this is what you are doing this would explain the behavior that you are seeing.

    regards

    swami

  • 0 in reply to swami
    Intellectual 470 points

    Swami,

    Thanks for the reply.

    I have modified msd_blkmedia_glue.c to eliminate the use of the MMC/SD.  Instead I simply copy data from SDRAM to the buffer in MSG_readLun.  On the PC the device shows up as a removable drive with RAW format.  It's possible that I've introduced a bug here, but what I'm doing is actually very simple.  I'll clean up my code a bit and post it later today.

    I agree that the bus is being reset, but I'm just not sure why.  Running USB tracing software I can see the STATUS_CANCELLED for one of the IRPs, but nothing of significance before that.  I don't have any hardware for doing bus analysis.

    I'm using TSCL/TSCH to monitor the number of cycles between calls to MSG_readLun.  The number of cycles agrees with 300 ms except when I get the stall.  Then I see that almost 10 sec after I expected a MSG_readLun I get the closeLun instead.

    Regards,

    Lori

  • 0 in reply to Lopi
    Intellectual 470 points

    swami,

    I think that I found a solution of sorts.  If I move the BIOSUSB-related .text, .far, and thread stacks to non-cachable SDRAM then my problem goes away.  Since I don't have access to the BIOSUSB source it is a little hard to debug further.  I'll keep my fingers crossed that as I build on my project further that the problem doesn't return.

    Lori