• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 1625 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430FR4133 Launchpad + CCS 6.1, app runs in debug mode but not free run mode

Derek Wright
Prodigy 80 points
Other Parts Discussed in Thread: MSP430FR4133

I'm loving the MSP430FR4133 Launchpad, but am new to CCS 6.1 so not sure if it's a CCS or MSP430 thing. When I run this code in debug mode it works fine, but if I power it up without being connected to CCS or press the reset button it seems stuck. It will sometimes execute some of the initial code displaying to the LCD then get stuck, or sometimes just get stuck out of the gate. How do I simply say "Debug is good, now just put the code on there without debug"?

Thanks!

  • 0
    TI__Guru 56685 points
    Derek,

    One way to do this while still being connected to the device is while in CCS and in Debug mode, you will stop at main() after loading the program. From here if you navigate to the Run Menu and chose Free Run, it will run the MSP without engaging the EEM, thus no debug capabilities will be present in this mode. One thing to note when running applications in full debug vs free run (or standalone) is that the MSP430 will run slower while in debug mode. This is due to the fact that the EEM is invasive. This means things will run faster when the EEM is disengaged. Issues can arise when race conditions occur within the code that cause it to get hung up on some condition within the code when free running, but when in debug mode the modules or interrupts have a chance to "catch up" with the core instruction execution.

    What causes this varies greatly with the application if you are having this issue. The best way I know to debug it is to use some spare gpios, and output them high when certain points of the code are reached. You can read this using some kind of logic analyzer or O-scope. (Its even easier if these lines are connected to LEDs!) By seeing which lines don't go high, you can see where the code is getting stuck. Form tere you can move these "GPIO Flags" to help narrow down where the issue in your code is. After this its an exercise of understanding what dependencies there are in the code at this point and seeing why they are not getting met.

    Regards,
    JH
  • 0 in reply to Jace H
    Prodigy 80 points
    Thanks for the insight - I think you're right. I think that there is a clock conflict that is being masked by the debug mode. I'll investigate and let you know, but this reply was extremely helpful - thanks!!!
  • 0 in reply to Jace H
    Prodigy 80 points
    Just to confirm, debug mode was masking that my timers were not being initialized in the right order. Also, my Run menu does not have a Free Run option, but it seems to work without CSS running now.

**Attention** This is a public forum