• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 80 subscribers
  • Views 1087 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430F5529 CDC virtual COM port

Jim Carlson
Intellectual 580 points

Other Parts Discussed in Thread: MSP430F6638, MSP430FG4619, TUSB3410, MSP430F5529, MSP430F5510

I had been using an old thread to find answers, and figured maybe it was time to start a new more timely thread. I am working with a MSP430F5529 device as a interim until I get more of the code and hardware defined to create a MSP430F6638 design. This design is going to replace a  MSP430FG4619 / TUSB3410 design with a desire to lower parts count.

I have the C1_Example running the CDC Virtual COM port demo and have been making changes to adapt it to replacing the MSP430FG4619 / TUSB3410 design. 

I have been having a nagging problem, that does have a work around. When I re-compile and download a new change, I can see the device re-register in device manager, but I am unable to connect to the COM port with either HyperTerminal or Putty [I am running on Windows 7 64 bit]. I have to physically unplug the USB and wait 5-10 seconds before reconnecting. 

Anyone know how to make a newly programmed device go through all the steps it would go through if it were freshly connected?

  • 0
    Guru 34973 points

    It smells to me that your target device is not resetting. Device must be configured, that USB reset (USBVECINT_RSTR) not reset only USB module, but also device itself (bis.b #FRSTE, &USBCTL).

    Go back with your code changes, until you reach version that is working OK, and than continue.

  • 0 in reply to zrno soli
    Intellectual 580 points

    I agree with your assertion that everything that needs to get reset is not getting reset.

    The code I am running is just the demo code [C1_Example] and I figured that this would have been something that would work in the Demo. The only thing I have added is some change of led state so I can see what happens, without having to set break points.

    This is not a big problem, but more an annoyance. My only concern is going forward, I want to be able to update code using the bsl. While it is not the end of the world to tell the end user to unplug and plug back in after a software update, I would like to figure out what is missing from the demo.

  • 0 in reply to Jim Carlson
    Guru 34973 points

    I remember that I have some reset/plugging related problem, but forget most of it, and notes in my last post are not correct. When device is plugged to USB port, host will made few resets at enumeration begin, and it must be able (USBCTL.FRSTE) to reset USB module with host reset command. This is already inside TI USB stack.

    If you are working with MSP430F5529, TI USB Stack examples are configured by default to work with MSP430F5529 with XT2 24 MHz, so there is no need to change something. Are you using MSP430F5529 as bus powered device (internal LDO), or there is separate 3.3V supply? I done testing of TI USB stack examples with MSP430F5510 without problems. I am working on project where are used 2 CDC ports. If I update firmware by USB BSL, or by my SBW+ programer, after firmware update device is reseted and enumerated without disconnecting/connecting USB cable.

    Try to update original C1_Example (without any source changes) by USB BSL tool, and check if there is need to disconnect/connect cable after firmware update, or device will be enumerated without problems.

**Attention** This is a public forum