• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 611 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 v4.1.0 & MSP430: rtslib changes and instabilities

gifford scott
Intellectual 380 points
Other Parts Discussed in Thread: MSP430F5438A

After downloading the new v4.1.0 version of CCS, I see that the C library support has been slimmed down: The linked executable is noticeably smaller and it appears that the 'l' length modifier is no longer supported for formatted printf output.  For example, printf("0x%lX") displays: "0xX".  My app uses the rts430xl.lib, intended for 430X devices.

Also, v4.1.0 seems less stable than v4.0.2 when attaching to the USB FET JTAG debugger:  For the MSP430F5438A target, I have to shut down and reload CCS v4.1.0 every time I rebuild the project that I'm currently debugging.  I loaded the CCS update w/the hope that it would be more stable, not less stable, than the current v4.0.2... but that doesn't appear to be the case.

regards,

gifford scott
DST

  • 0
    TI__Guru**** 173310 points

    For the rtslib changes, yes, the default build in CCS 4.1 includes the option --printf_support=minimal. You can see this in the Build Properties->C/C++ Build when you highlight MSP430 Compiler. This option links in a minimal version of printf support, details of which can be found in the MSP430 Compiler Users Guide, http://www.ti.com/lit/slau132. You can change the support to full or nofloat versions by modifying the option.

    To verify which version of printf is getting linked in you can look at the link map file generated by default in the \Debug or \Release folder.

    In CCS 4.0.2 also the build option --printf_support=minimal was present but there was a bug in that it wasn't being passed correctly to the linker, so if you compare the link map files between CCS 4.0.2 and 4.1.0, you will notice that the full version of printfi is linked in for CCS 4.0.2, while the minimal version of printfi is linked for CCS 4.1.0. This would also explain the smaller size of executable in 4.1.0.

  • 0 in reply to AartiG
    Intellectual 380 points

    Thanks Aarti.  That is what was happening with the rtslib - the --printf_support option needed to be changed to'full' in v4.1.0.2003.

    The instabilities in v4.1.0.2003 are still an issue: I can switch between projects, select Target->'Debug Active Project', and then see the 'Erasing Memory' and 'Loading' progress windows come up.  After that happens, all the Target debug selections remain grayed out, such as Run, Halt, Connect Target, etc.  In addition, 'Launch TI Debugger' is grayed out, but 'Debug Active Project' is still selectable.  There seems to be no way to use the debugger once CCS goes into this state - very frustrating.  Are you aware of this issue?  I'll include a screen print in the next post.

  • 0 in reply to gifford scott
    Intellectual 380 points

    CCS v.4.1.0.2003, after selecting 'Debug Active Project':

  • 0 in reply to gifford scott
    Intellectual 380 points

    I've figured out why the Target options stayed grayed out: I had closed the 'Debug' view.  If I open the Debug view, the Target options become active.  If I close the Debug view, the Target options become grayed out.  In either case, it's apparent that the debugger is running, but with the Debug view closed, the debugger menu functions cannot be accessed.  Very irritating - please tell me that this behavior is not considered a 'feature' and that you will consider fixing this issue...

    regards,

    gifford scott

    DST

  • 0 in reply to gifford scott
    TI__Guru**** 463941 points

    The reason for the the options being greyed out  is because there is no active debug context when the Debug view is close. This makes sense if you are working on a multi-core target and you need to specify which core has context in the Debug view. On a single core, you can argue that this should not be an issue. But it is a feature we inherited from Eclipse and in our ongoing efforts to comply to Eclipse standard, we will not try to deviate from this behavior.

    Thanks

    ki