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 execution suspends randomly during debug without any breakpoint

Other Parts Discussed in Thread: MSP430F5326, TPS3823

HI.

I'm using ccsv5 and msp430f5326. All works really fine. But when I test the device for long time (minutes / hours) in debug mode the execution is stopped, actually suspended, like there was a hidden breakpoint. The problem maybe is similar to the one  Posted by Braddon Van Slyke on  Jun 28 2012 13:31 PM.

I can simply push the Resume(F8) button and all works fine, but i'm not so quite sure. Can I sleep these nigths?

There are some our company's client rising some trouble with our devices (sold worldwide for several power plants) that seem indicate a reset of the microcontroller two, three times a day.  If the execution is interrupted then an external watchdog (TPS3823) will reset the MCU.

Maybe  I have done something wrong in ccs configuration?
Can you please suggest some kind of investigation?

Please help me. I can send to you the information that you think usefull.

Thank you.
Giandavide

 

  • giandavide curto said:
    But when I test the device for long time (minutes / hours) in debug mode the execution is stopped, actually suspended, like there was a hidden breakpoint.

    I would be surprised if the CCS tools themselves caused the program to halt unexpectedly. It is more likely that it is something in the hardware or code that is causing the issue. Is ti always halted at the same location or at random different locations?

    I am moving this thread to the MSP430 forum so the experts and broader community there can chime in with their suggestions as well.

     

  • AartiG said:

    I would be surprised if the CCS tools themselves caused the program to halt unexpectedly. It is more likely that it is something in the hardware or code that is causing the issue. Is ti always halted at the same location or at random different locations?

     Hi Aartig, I also experience this kind of trouble on IAR too, this is more frequent running on windows software than on Linux but for MSP430 I don't own a supported interface.

     This happen when I run a motor attached to an MSP430 H bridge board, spikes and or  some EMI seems to stop debugger probe. This happen also on remote controller when no EMI shielding was on communication cable. My actual FET is Elprotronics one but Olimex (ISO and RF too), TI FET all suffer same trouble, shortening FET cable and filtering of reset and test (reset most sensitive) connection close to processor reduce this threat but is not possible to eradicate from board under debugger. Attaching 20 cm of wire on reset are enough to exploit this issue, so cabling cannot stay on debug socket  free flying nor with a FET too.

     Motor controller and remote controller both run fine for long time when no debugger is in place.

  • Hi  AartiG.

    Thank you for attention.

    I have other things to tell that maybe can be usefull:

    AartiG said:
    It is more likely that it is something in the hardware or code that is causing the issue.


    Probably you are right but... can you please tell me...

    How can I with the hardware halt the execution and to communicate to the CCS which exact line of C code to be highlighted?
    How can I with the code halt the execution and to communicate to the CCS which exact line of C code to be highlighted?

    AartiG said:
    Is ti always halted at the same location or at random different locations?

    Seem that the micro is halted randomly only the first time and subsequently always in that point, often the first C instruction of an ISR.

    Another way to avoid these execution suspension (like hidden breakpoint) is to terminate the debug session ( square red button) and leave the micro running with the JTAG connector plugged. The device then doesn't halts no more but I have lost the ability to debug.

    Thankyou in advance.

  • Hi Roberto,Thanks for attention.

    Roberto Romano said:
    spikes and or  some EMI seems to stop debugger probe. This happen also on remote controller when no EMI shielding was on communication cable


    When my application suffers some EMI, I usually lose the communication between CCS and Target.
    In this Hidden-breakpoint's problem this is not the matter. In my experience the communication with the target holds very well, the execution is suspended (like a double pipe button pressed or an hidden breakpoint hits) and I can always resume (green triangle button) . Is this the kind of trouble that you have in your experience?

    Thankyou.

**Attention** This is a public forum