USB boot issue

Hi Omkar,

It looks like you have to check if your prototype is ok with this

http://www.ti.com/lit/er/sprz308a/sprz308a.pdf

specifically on page 15.

Christos

Hi Christos,

      As per the document both the CPUs are having "Silicon Revision 2.0". The nomenclature "TMS" denotes "Fully-qualified production device" compared to "TMX". Along with tools, TI has provided the document about the needed changes. The external power supply change ( "Advisory 2.0.9" in the document you have referred) is  one of them. The same I have done on EVM and our prototype. The EVM is working but our prototype is not working. If  "TMS" denotes "Fully-qualified production device" it should work same way as EVM. 

    Thank you for the document. It has given me few more details. 

----

Omkar

Omkar,

Christos is correct. They should work the same. You might try uninstall the USB device from Device Manager and try again.

Regards.

Hi Steve,

   "Driver details" is showing as "No driver files has been loaded for this device". I tried uninstalling and updating the drivers but there is no result.

    I have one more query other than USB boot. I tried to check the connectivity using the "CSL_USB_PollExample" in CSL2.50. The same example showing connectivity for

"EZDSP/EVM 5515" but not our prototype. The device is getting hang if use this example. I have debugged for this issue. The following line in the "USB_init" function  is

causing the problem. 

CSL_FINS(usbRegisters->FADDR_POWER, USB_FADDR_POWER_HSEN, TRUE);

The line is setting the particular bit which is already set by default. If I use the following line instead of above line my device is getting connected and working properly.

usbRegisters->FADDR_POWER &= ~0x2000;

I have reset the bit instead of set. This change was compulsory for the connectivity. Can you guess why this is necessary? Do you have any other suggestions

for the USB boot.

Thanks & Regards,

Omkar

  Yes, the device is enumerated as "C5515" and the device is working properly in full-speed mode. If I configure the device in HI-speed mode the device is not going beyond init

function itself. The device is getting disconnected immediate after the following line in the "USB_init" function.

CSL_FINS(usbRegisters->DEVCTL, USB_DEVCTL_SESSION ,TRUE);

  We are using mini-usb 2.0 connector. It is having 5 pins. In the EZDSP pin 4 is not connected and pin 5 is grounded. But in our prototype the 4, 5 pins are grounded. Will it make

any impact on HI-speed mode? What could stop the device running the device in high-speed mode.

> The device is getting disconnected immediate after the following line in the "USB_init" function.

> CSL_FINS(usbRegisters->DEVCTL, USB_DEVCTL_SESSION ,TRUE);

Debugging a USB connection issue on a C5515 app, I stumbled upon this line of code in CSL's USB_Init() and determined that it was an *EVIL* thing.  (FYI, I'm using CSL 2.50).  I was trying to figure out why the DSP USB was physically connecting to the USB bus, prior to all the desired USB initilization was being performed both in and outside of USB_Init().  Turns out that when the SESSION bit is set in the USB DEVCTL register the SOFTCONN bit is getting set in the USB DEVCTL POWER register as a most undesirable byproduct.

The SOFTCONN bit was cleared by the reset of the USB module near the beginning of USB_Init() and technically, you'd want it to stay that way until you've completed fully configuring the dang USB and everything that will I/F with it and are ready to actually deal with its operation in your app, like when you finally call USB_connectDev() which sets the SOFTCONN bit.  The setting of the SOFTCONN when SESSION is set while stepping thru USB in a debug session will cause your OS to complain about a device enumeration problem.  This is because the DSP USB is enabled on the bus before it's ready for prime time.

I tried relocating the setting of the SESSION bit,  to USB_connectDev() but that caused too much grief as the USB I/F sort of worked, but in the end it actually sort of stumbled along not quite performing as expected.

The docs (USB 2.0 Controller User's Guide, SPRUGH9) provide info on the SESSION bit and its some of its consequences, but don't really speak to the SOFTCONN issue.

Anyone at TI care to shed some light on this?

-Jim

Hi all,

   The issue is fixed. There was some redundant resistor in the path of data(D+, D-) lines. The USB boot is working fine. Thanks for your support.

Regards,

Omkar