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.

USB device always goes into speed

Other Parts Discussed in Thread: OMAPL138

Hi

I'm using Starterware 1.20.4.1 on a c6748 as a CDC device. I wrote my own code based on the CDC example. It works fine at high speed when connected to a PC, but when connected to custom hardware it fails almost immediately after the high-speed chirp. Most probably this is due to the quality of the connection, impedance mis-match, etc.

As a quick fix, I want to use full speed, which ought to be far less demanding on the connection. And it's fast enough for the application, so it could very well become a permanent fix.

I have rebuilt the usblib, adding my own code to clear the HSEN bit in the USB 'POWER' register (0x1e00401). But this doesn't work. After the call to USBDevConnect() the power register reads 0x50, (i.e. HSMODE=1) indicating the high-speed mode has been successfully negotiated - even though HSEN=0!

Then I saw this conversation: https://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/355976

so I reverted to the original usblib, rebuilt drivers.lib instead, adding the line  #define USB_MODE_FULLSPEED to usbphyGS60.c.

I wasn't hopeful, because it basically clears the HSEN bit, same as I had been doing in usblib. Sure enough, I still see HSMODE bit is set after connecting.

I have double checked that I'm linking in the newly built driver.lib, not the old one. So why do I still get HSMODE bit set?

Please can anyone help?

  • Hi Roy,

    We will get back to you shortly.
  • OK, this is strange, because the usb is actually operating correctly in full-speed mode. Its just that the HSMODE bit is 1.

    But, if I read the HSMODE bit again (several seconds later) it is 0. So all's good in the long term, it's just reading status immediately after connecting that it gets the wrong value. So, I don't actually have a problem, just that I've seen inconsistent behaviour.

    Roy
  • Hi,

    _

    The MSC Host class is by default configured for Hi-Speed DMA transfer mode. For Full-Speed mode, define 'USB_MODE_FULLSPEED' in 'Drivers', 'USBLib' and 'Application' make files.

    I hope, we need to define this variable in drivers.lib, usblib.lib, and other libs also....

  • A quick grep tells us that USB_MODE_FULLSPEED is found only in 3 files

    drivers\usbphyGS60.c - 1 match in 121 lines.
    drivers\usbphyGS60.c 90 #ifdef USB_MODE_FULLSPEED
    drivers\usbphyGS70.c - 1 match in 108 lines.
    drivers\usbphyGS70.c 75 #ifdef USB_MODE_FULLSPEED
    include\cppi41dma.h - 2 matches in 433 lines.
    include\cppi41dma.h 91 #ifdef USB_MODE_FULLSPEED
    include\cppi41dma.h 95 #endif /* USB_MODE_FULLSPEED */

    and in cppi41dma.h it only affects packet size, so I think it's enough to rebuild only drivers.lib

    The question remains though, why does the HSMODE bit go high for a little while when HSEN is low? I guess it's not important.

    Roy

  • Roy,

    I just experimented the USB dev msc example in High speed mode on OMAPL138 LCDK board. As you observed, it worked in high speed flawlessly.

    If we can do a tweak in the configuration, it should work in Full-speed too. But this needs effort too.
    By the way, real time, through the debugging window, able to set the HSEN register manually "0" and hence the HSMODE can also be zero. But I cannot assure this through to completion ( I mean, that the device is full speed operable by downgrading from high speed operable )

    AS I did in the debug window, I would recommend you to do it through the source flow and set the HSEN low. I understand, you did the same in your own CDC code. Please try out the same in this example.
     
    Please try out this simple USB dev MSC eexample by modifying the configuration for full speed USB dev MSc.

    By the way, the HSMODE and HSEN are ofcourse important.