• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 80 subscribers
  • Views 2226 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.

CCS/MSP430F5529: Disconnecting/Reconnecting USB workaround

Mark Anderton22
Intellectual 360 points

Part Number: MSP430F5529

Tool/software: Code Composer Studio

Hi All

We have a bootloader (not using the BSL) and application on our processor. We connect to the device via USB in a windows C# application we are using, through this we select a firmware image to send to the bootloader in order to flash the image. This all works fine.

When the image is flashed in the bootloader, the bootloader jumps to the App. Here the processor reconfigures and carries on running, but we lose the USB connection to the application.

If we remove the USB (from PC app to USB on the embedded device) and plug it back in, the USB starts to work again. We can also go into device manager, right-click the MSP430 USB and disable/reenable to get it to work.

We release the comm ports in the c# app and we also run the library functions in the embedded to release the USB.

We initialise with this (on both):

USBHAL_initClocks(24000000);                         // Config clocks.
USB_setup(TRUE,TRUE);                                  // Init USB & events; if a host is present, connect

 We close off with this (on both):

       USB_disconnect();
       USB_disable();
       _disable_interrupts();
       SYSCTL &= ~SYSRIVECT;                     //Turn off RAM interrupts
       ((void (*)()) APP_RESET_VECTOR) (); //Jump

When we go from the App to bootloader, we use a BOR instead of jump as our reset vector is always in the bootloader. 

              USB_disconnect();
              USB_disable();
              BROWN_OUT_RESET // This will cause a BOR and will start the boot loader

We are using the latest TI stack for the MSP430

The question is, how do we get the USB connection to remain or refresh so that we don’t have to physically disconnect and plug in again? I think this potentially could be a windows side problem but thought I'd check if there was a way to do this on the embedded side first. Let me know if you need more info.

Thanks.

  • 0
    Guru 34973 points

    I use my own (CDC) BSL for updating firmware on similar device. When BSL update is finished PC side (Win / Linux / OSX) send reset command to MSP, and immediately close the serial (CDC) port. MSP reset itself by WDT timeout, and start main application, where it is again enumerated by OS and ready to go.

  • 0
    Guru 326260 points
    In theory, disconnecting and disabling the USB module should be seen as a disconnection by the host.

    How much time between the bootloader and the app? Could you try to insert a delay?
  • 0 in reply to Clemens Ladisch
    Intellectual 360 points
    Thank you for your responses so far. I did put in a 5 second delay between disconnection and re-connection and the same thing happens.

    I believe this may be on the windows side now. We have a Port Event handler on the C# application so when a USB device is connected or disconnected, it can detect it and take the appropriate action, it listens to the registry entries in HKEY_LOCAL_MACHINE\\HARDWARE\\DEVICEMAP\\SERIALCOMM

    What we have found is when we add or remove USB devices (of any kind), this event fires and you can see the connections in the Windows registry and Device Manager appear (connect) and disappear (disconnect), but strangely for the TI MSP430 USB connection - when it is disconnected it is removed from the Device Manager but not from the Windows Registry, this is the only case. This is why we are not getting a reconnection, because it's not seen the disconnect.

    My knowledge of Windows drivers isn't 100% so correct me if I'm wrong but I think this may be either a problem with the Serial Comm driver from TI not de-registering correctly or our C# application is not fully releasing it. This has been tested on Windows 7 and 10.

    We will keep trying and keep you updated.

    Thanks again.
  • 0 in reply to Clemens Ladisch
    Intellectual 360 points
    Hi All

    Just an update, we have discovered that the entries in the registry are somehow duplicating themselves. This seems to be out of our control and we are not sure why this is happening, but we have now fixed this by performing two port disconnects in the C# application. This then successfully detects the disconnection and re-connection of the ports.

    Thanks for the suggestion of doing it with device notifications, this is probably a more valid way but unfortunately I'm just the embedded engineer and the application engineers want to keep it the way it is in the C# application, due to the restricted rights on the users PCs, but it is working now anyway.

    Thanks again.

**Attention** This is a public forum