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/MSP-EXP430F5529LP: MSP430F5529

Part Number: MSP-EXP430F5529LP

Tool/software: Code Composer Studio

Developing on the 5529LP, using USB CDC receive only and SPI (A) send only, it unpredictably freezes anywhere from < 3 minutes to over an hour after start.  I didn't discover the problem until I tried simulating the final system which will be unattended.  When it locks up, occasionally the evb reset button will allow a restart but most often only a disconnect/reconnect and restarting the host app will work.  This won't be possible with the host unattended.

I eventually tried a pristine copy of example C1_LedOnOff and it does the same.  I have a LabVIEW test routine that repeats "LED ON" "LED OFF" commands with adjustable delay time.  Faster repeats (up to 50msec) seem to make the problem occur sooner but it's not consistent enough to be predictable.

This can be replicated on an out of box 5529LP board and fresh copy of C1_LedOnOff example code.  Running in debug mode or downloading a release version doesn't seem to affect it at all.  As a test I tried commenting out the reply communication with no effect.

Just updated to the latest CCS 1010 with no improvement, running Windows 10 on a desktop workstation.

  • Hi Tom,

    You means that the MCU will freeze just use USB CDC receive only and SPI (A) send only?

    Could you provide test demo that I can test in my side.

    Best Regards

    Johnson

  • Yes, even without the SPI.  After troubleshooting and removing sections of my code I started again with a fresh copy of the demo code (C1_LedOnOff) and it behaved the same.  I then commented out the response portion so it was receive only plus LED control and it still behaved the same. 

    (so CDC receive and LED GPIO only, the rest as originally provided)

    Tom

  • If you have access to LabVIEW I can send a small demo VI that exercises the USB or send a larger compiled version.

    Otherwise maybe write a simple Windows test app (Python maybe), the algorithm is pretty straightforward:

    Zero an event counter

    Start a total duration timer

    LOOP (forever)

    Send "LED ON"

    increment event counter

    wait(some_msec)

    Send "LED OFF"

    increment event counter

    wait(some_msec)

    back to LOOP

    While operating you should be able to observe the LED on the F5529LP board blinking

    When if freezes, the event counter and duration timer should also freeze so you don't need to watch it, just check periodically.

  • Stress testing is still underway, but it now seems the original problem was due to an external USB backup hard drive.  There had been no such issues before these tests began so it may have been an unfortunate coincidence.  The fact that time to fail is unpredictable means an extended test is necessary.

    After current testing finishes tomorrow, I'll try to replicate the failure and then verify the fix, and then close this issue.

  • Problem resolved:

    I'm confident now that the USB issues were all due to a failing external drive on the workstation.

    If anyone has similar stability problems in the future, recommend removing as many other USB devices as possible and testing again.

**Attention** This is a public forum