• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 53 subscribers
  • Views 3246 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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/TMS320F28379D: USB com port not enumerated in Windows device manager when running IDDK_PM_Servo_F2837x-v2 project

Earl Green
Prodigy 140 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: CONTROLSUITE, DESIGNDRIVE, C2000WARE

Tool/software: Code Composer Studio

Hello,

I have posted on here recently with a problem related apparently to the CCS debugger or perhaps the CCS projects included in the controlSuite support software. I have validated that this problem does not exist with the usb_dev_serial_cpu1 project.

We recently purchased the DesignDRIVE Development Kit IDDK as shown here: www.ti.com/.../TMDXIDDK379D. We then developed software around the TI chip and this development board using the IDDK controlSuite project, but we have noticed that when we launch the debugger within CCS, the code loads onto the controller and the debugger runs to main(). When we proceed into the main() function with or without breakpoints, a USB com port does not shown to be enumerated in Windows Device Manager, and we sometimes receive a Windows notification that the last USB device was not recognized. After purchasing the DesignDRIVE kit, it seemed logical that we would begin software development with the IDDK controlSuite project.

When we use the usb_dev_serial_cpu1 project from controlSuite, we can still load the code onto the controlCARD. But the difference is that when this project halts at main() and we step into main() with or without breakpoints set, the Windows Device Manager does show a USB COM port enumerated under "Ports (COM & LPT)". Clearly, after we terminate the debugger and disconnect the USB cables from the host PC the COM port disappears. However, this [assumingly correct] behavior only occurs when running the usb_dev_serial_cpu1 project. What is the difference between these two projects? It is desired to replicate the behavior of the usb_dev_serial_cpu1 project in other CCS projects, specifically the IDDK_PM_Servo_F2837x-v2 project.

When debugging both projects, usb_dev_serial_cpu1 and IDDK_PM_Servo_F2837x-v2, I believe I isolated the problem to the function call void *USBDCDCInit(uint32_t ui32Index, tUSBDCDCDevice *psCDCDevice) within the TI USB libraries. The execution of this call in the usb_dev_serial_cpu1 project causes the enumeration of a COM port in Device Manager. However, the same execution of this call in the IDDK_PM_Servo_F2837x-v2 project does not cause the enumeration of the COM port. When looking into the USB library, namely the file usbdcdc.c/.h, I see that USBDCDCInit contains a call to USBDCDCCompositeInit(ui32Index, psCDCDevice, 0) as well as a call to USBDCDInit(ui32Index, &psInst->sDevInfo, (void *)psCDCDevice).

Thank you for the help on this matter,

Earl Green

  • 0
    TI__Mastermind 32995 points
    Earl,

    What is the IDDK project doing? Are you using two USB cables? Or one USB cable? What is being connected to what?

    It is right that the usb_dev_serial would connect to the PC as a comm port. I am not sure the IDDK is using usb and should show up as a seperate comm port.

    Additionally, the micro-usb connector on he controlCard has the ability connect to the debugger and SCI pins through an FTDI chip to act as a comm port. This may be what you are seeing. These two things can happen at once.

    sal
  • 0 in reply to Sal Pezzino
    Prodigy 140 points
    Sal,

    I am using two USB cables, micro and mini USB. Both dip switches, A:SW1 for UART and JTAG are switched to the on position. Both cables are connected to the pc.

    The fact that we bought an IDDK development board, we decided to use the IDDK project as a starting point for the code. However, we still need communications through a com port to happen and the IDDK project does not include code for USB functionality, so we have integrated the USB code into this project.

    Earl
  • 0 in reply to Earl Green
    TI__Mastermind 32995 points
    You can use the SCI to communicate serially to the PC. You may wish to do this. This should be possible using the mini-USB connector and the FTDI chip. Does your board have an FTDI chip on it to mux the SCI pins through the mini-usb connector?

    Using SCI will be easier to develop and debug.

    sal
  • 0 in reply to Sal Pezzino
    Prodigy 140 points
    The board does have an FTDI chip so I could use the SCI interface to the chip for development and debugging.

    Earl
  • 0 in reply to Earl Green
    TI__Mastermind 32995 points
    I suggest using that if you are looking for a COMM port to the PC instead of using the USB in CDC mode.

    sal
  • 0 in reply to Sal Pezzino
    Prodigy 140 points
    We load code written in Code Composer Studio over the JTAG interface to the target F28379D chip. With the example projects supplied by TI, namely usb_dev_serial_cpu01, once the code has been loaded onto the board and it is running from RAM, the COM port is enumerated and talks through the micro-USB cable. I can verify this because once the program has loaded, I can detach the mini-USB cable and we can still talk to the device.

    Would the COM port to the PC only support host communication or would the SCI interface also be used for debugging and loading the program through JTAG?

    Thanks,
    Earl
  • 0 in reply to Earl Green
    TI__Mastermind 32995 points
    The COM port over the mini-USB and FTDI chip would only be used for serial communication. However, the mini-USB can also be used for JTAG as you are currently doing this.

    The usb_dev_serial also demonstrates how to use the SCI for communication over the mini-USB as does the sci examples in C2000Ware.

    Let me know if you have any other questions.

    sal
  • 0 in reply to Sal Pezzino
    Prodigy 140 points
    Ok, thanks for your help. I will let you know if anything else comes up.

    Thanks,
    Earl
  • 0 in reply to Earl Green
    Prodigy 140 points
    Hi Sal,

    In our IDDK project, at the start of main() we use InitSysctrl() in order to initialize system control for the PLL, WatchDog, and Peripheral Clocks, which is called from F28M3Xx_SysCtrl.c. The usb_dev_serial project uses SysCtlClockSet(SYSCTL_OSCSRC_XTAL | SYSCTL_PLL_ENABLE | SYSCTL_IMULT(20) | SYSCTL_SYSDIV(2)). Could this difference be causing the failure of the USB com port to enumerate in Device Manager?
  • 0 in reply to Sal Pezzino
    Prodigy 140 points
    Hi Sal,

    In our IDDK project, at the start of main() we use InitSysctrl() in order to initialize system control for the PLL, WatchDog, and Peripheral Clocks, which is called from F28M3Xx_SysCtrl.c. The usb_dev_serial project uses SysCtlClockSet(SYSCTL_OSCSRC_XTAL | SYSCTL_PLL_ENABLE | SYSCTL_IMULT(20) | SYSCTL_SYSDIV(2)). Could this difference be causing the failure of the USB com port to enumerate in Device Manager?
  • 0 in reply to Earl Green
    TI__Mastermind 32995 points


    I don't believe so. It looks like it is setting up the PLL for 200MHz.

    sal