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.

CC2538 USB Connection via the EM (not SmartRF06EB's USB): Disconnection issue.

Other Parts Discussed in Thread: CC2538, CC2531

Hello,

I have enabled the CC2538EM's USB port in my ZStack Energy project, and I have a working virtual COM connection in Windows (8.1). The post by Se-Hee Whang, dated Fri, May 23 2014, called "cc2538 usb_uart", helped me to do this.

I have an unusual problem that I can't solve:

The ESP in that project does not connect properly. When I plug in the USB cable to the EM's USB port, it connects very briefly to the PC, and then disconnects itself immediately. The device manager in windows shows this.

I think that during my development on this ESP, I have disabled something that the USB module needs. Does anyone perhaps know what that might be? Are there maybe some defined symbols, USB-related, that are not able to be active at the same time as others?

Or maybe it is another problem?

Thanks for your time.

  • Do you have a serial bootloader in the project? Maybe the brief connection is the bootloader connecting USB, then when the bootloader boots into the application it gets re-enumerated.

    If so please look at the zstack-home-1.2.1 CC2531 serial bootloader, there is a fix for this in the bootloader so the USB does not re-enumerate.

    Regards,
    TC.
  • Hi TC, thanks for the response,

    I don't think that its the boot-loader causing this, because when I use TI's original unedited ZStack on my CC2538EM with the "HAL_UART_USB" defined symbol, the CC2538EM's USB works fine -I get a stable device called "TI CC2538 USB CDC Serial Port (COM5)" in my Windows Device Manager.

    Its only when I use our edited ZStack, that the device does not remain in the device manager.

    But Im not that familiar with serial boot loaders, so maybe you are correct?. Is there maybe an area of ZStack that I could search for to check the serial boot loader?

    Thanks for your time.
  • Hi TC,

    It seems that I have fixed my problem: I now have a stable USB connection between my CC2538EM and PC. By slowly re-editing our esp.c code from its original to the way we want it, I have determined that it was this line that caused the USB to disconnect itself:

    HalLedBlink ( HAL_LED_1, 1, HAL_LED_DEFAULT_DUTY_CYCLE, HAL_LED_DEFAULT_FLASH_TIME );

    This line was in the " uint16 esp_event_loop( uint8 task_id, uint16 events )" function, under the event: "if ( events & ESP_UPDATE_TIME_EVT )".

    Perhaps the timer used by the HalLedBlink function is also used by the USB module, and there is a clash or something.

    I have not had a chance to properly test this, so this may not be the root cause of the problem, but I thought I should just put this here for now, in case others are having similar problems. Once I have tested this properly tested this, I'll reply here with any info that I have.
  • I have discovered the actual problem in this issue:

    If one looks at the schematic of the EM (CC2538), PortC0 is linked to the USB port as a driver for a pull-up resistor. Port C0 is also the output for LED1 (HAL_LED_1 from the previous post) ! So when the LED was set high, the USB module probably shut down.

    So it seems that the EM's USB port and LED1 ( on the SmartRF06) cannot be used at the same time.

    I did not notice this conflict mentioned in any of the documents that came with the kit, but there are many documents, and I might have missed that section if its there!
  • Hi,

    How can you fix this problem?

    We faced the same problem...kindly help this by giving a solution.

  • Dan found that LED1 and USB are conflicted. You can try to set "#define BSP_LED_1 GPIO_PIN_0 //!< PC0" to "#define BSP_LED_1 GPIO_PIN_1 //!< PC1" in bsp.h and see if it works.
  • Yes, a good suggestion by YK Chen. 

    Also, if you are using any of the "GPIO..." functions in your code, like "GPIOPinWrite", make sure that none of them refer to the Port C0 labels, " GPIO_C_BASE, GPIO_PIN_0, ... ", so do a broad serach for "GPIO_C_BASE, GPIO_PIN_0".

    If you're not using the LEDs on the SmartRF06, you should disable the LED functions by ensuring that the "HAL_LED" compile flag is disbaled (xHAL_LED), and changing the default definition for HAL_LED in the file named "hal_board_cfg.h" ...

    >>>

    /* Set to TRUE enable LED usage, FALSE disable it */
    #ifndef HAL_LED
    #define HAL_LED TRUE   //  ***** This line should be changed to "#define HAL_LED FALSE"  *****
    #endif
    #if (!defined BLINK_LEDS) && (HAL_LED == TRUE)
    #define BLINK_LEDS
    #endif

    <<<

    Hope that this helps.