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.

CCS/TMS320C6748: Connect USB when already connected

Part Number: TMS320C6748
Other Parts Discussed in Thread: OMAPL138

Tool/software: Code Composer Studio

I am using a TMS320C6748 as a USB2.0 device. Whenever I start a debugging session from CCS, the usb device appears in the Windows device manager. When I disconnect CCS from the target and then start a new debug session, the USB device is disconnected from the bus during the call to USBDBulkInit. More specifically, it is disconnected when setting the RESET bit in the CTRLR register. I understand that the USB device is disconnected from the bus when the USB hardware is reset, but what can I do to bring it back on the bus?

Some lines after the reset, the following code is executed

// Make sure we disconnect from the host for a while.  This ensures
// that the host will enumerate us even if we were previously
// connected to the bus.
//
USBDevDisconnect(USB0_BASE);

//
// Wait about 100mS.
//
delay(100);

//
// Attach the device using the soft connect.
//
USBDevConnect(USB0_BASE);

It looks like this is meant for exactly my case, but it doesn't bring my USB device back on the bus

  • Timon,

    Sorry for the delayed response on this topic. Are you running this experiment on the C6748 LCDK using Starterware ?
    It may be best if you can tell us how we can reproduce this on our setup so that we can provide some guidance on this.

    Regard,
    Rahul
  • Hi Rahul,

    We are running the experiment on a custom board based on the C6748 LCDK. The issue seems to be that the USB library doesn't handle pending USB interrupts correctly. We have been able to solve the issue by adding some code to StarterWare. In the file usbdenum.c, in the method USBDCDInit, we have changed the code from

    USBReset(USB_0_OTGBASE);
    
    //
    // Turn on USB Phy clock.
    //
    UsbPhyOn();

    to

    USBReset(USB_0_OTGBASE);
    
    USBClearInt(USB_0_OTGBASE);
    HWREG(USB_0_OTGBASE + USB_0_END_OF_INTR) = 0;
    
    //
    // Turn on USB Phy clock.
    //
    UsbPhyOn();

    Please let us know if you think this is correct.

  • Yes, this code appears to be correct way to implement the fix. We are still checking with internal design folks whether the interrupt should be cleared explicitly after soft reset of the USB controller or is there another way to reset the module so that the interrupts are cleared.

    Other devices like AM335x with similar USB controller has a USB wrapper implemented which allows subsystem level reset which is how the Linux drivers are implementing it but for C6748 and OMAPL138, this might be the only way to handle the pending interrupts or clearing previous interrupt settings.

    Regards,
    Rahul