RobG 1,892 Posted October 18, 2013 Share Posted October 18, 2013 I am running into some problems with CCS. I have a program that is under 5k and uses ~1200 bytes of RAM. When I increase couple of arrays by about 200 bytes, the program compiles but then it does not let me debug. It appears to be running, but it isn't (see attached pic.) Clearly, there's some kind of limit here, but what? I had code size limited version of CCS, so I have activated my license (after 2 years ,) it's a full version now. I have tried F5418A and F5419A, same results, LaunchPad and FET430UIF, still same results. Quote Link to post Share on other sites
bluehash 1,581 Posted October 18, 2013 Share Posted October 18, 2013 I have CCS5, if you want me to test it on it. Quote Link to post Share on other sites
RobG 1,892 Posted October 18, 2013 Author Share Posted October 18, 2013 I did a simple test program with large array and it worked. Will try to upgrade to CCS6 and see if that will do the trick. Quote Link to post Share on other sites
RobG 1,892 Posted October 21, 2013 Author Share Posted October 21, 2013 Installed CCS6, same thing. Installed CCS4, it works! Go figure. Quote Link to post Share on other sites
RobG 1,892 Posted November 5, 2013 Author Share Posted November 5, 2013 Found the problem (thanks to Jens-Michael Gross from e2e.) As it turns out, _auto_init was taking too long and WDT was resetting MCU before debugger could get to main breakpoint. Adding _system_pre_init and disabling WDT before _auto_init fixed my issue. int _system_pre_init( void ) { WDTCTL = WDTPW | WDTHOLD; return 1; } bluehash 1 Quote Link to post Share on other sites
bluehash 1,581 Posted November 5, 2013 Share Posted November 5, 2013 Compilers acting differently? Quote Link to post Share on other sites
RobG 1,892 Posted November 5, 2013 Author Share Posted November 5, 2013 asm produced by CCS4 is different than the one from CCS5. Also, there's a setting in CCS that will hold WDT during cinit, but I cannot find it in CCS5.4 (was it removed?) More about it here: http://processors.wiki.ti.com/index.php/MSP430_FAQ#WDT_fires_during_C_startup_code bluehash 1 Quote Link to post Share on other sites
RobG 1,892 Posted November 6, 2013 Author Share Posted November 6, 2013 There's another way CCS (I am not sure if I should use .TI.noinit, but using .noinit or any other section does not work) #pragma DATA_SECTION(myVar, ".TI.noinit"); unsigned char myVar[2][512]; IAR __no_init unsigned char myVar[2][512]; mspgcc (see pabigot's note 2 posts below) unsigned int myVar[2][512] __attribute__ ((section(".noinit"))); Quote Link to post Share on other sites
bluehash 1,581 Posted November 6, 2013 Share Posted November 6, 2013 Thanks @RobG May avoid some hair pulling in the future. Quote Link to post Share on other sites
pabigot 355 Posted November 6, 2013 Share Posted November 6, 2013 mspgcc (not sure about .noinit, see CCS example) unsigned int myVar[2][512] __attribute__ ((section(".noinit"))); This works, but is unnecessary on mspgcc: the C runtime (CRT) code that zeroes bss and copies statically initialized data resets the watchdog while it's working. The watchdog is also reset between each static constructor or destructor call. You can also globally disable the watchdog with -mdisable-watchdog, in which case it's disabled before any of the CRT stuff gets going. bluehash and RobG 2 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.