CCS V5.3 MSP430 compiler run time initialisation lockup!

1. If "whatever" is never modified, it certainly would be better as a const object.  However, the compiler team doesn't produce MSP430ware, so you'll need to post that question to the MSP430 forum.
2. I cannot guess why such a bug slipped through without analyzing the bug.  To do that, I'll need a test case.  When you say "any example," are you talking about an example that comes with MSP430ware?  If so, could you name one for which you have observed the failure?  If not, could you post the source code and command line options for the test case demonstrating the bug?
3. The correct place to report compiler bugs is now this forum.  Could you please tell me the URL of the web form you are referring to?

A simplifed example is below:

// ******** START OF EXAMPLE CODE *********

#include <stdio.h>

#include <msp430f5435A.h>

#define CRASH_ME 1

// the following was taken from a MSP430ware example and reduces to a few illustrative lines previously called unsigned short usci_a_uartbaudrate_UCSx_mod[8][8] =

/* LINKER SECTIONS AS PER COMPILER DEFAULT lnk_msp430f5435a.cmd

SECTIONS

{

    .bss        : {} > RAM               

    .data       : {} > RAM               

    .sysmem     : {} > RAM               

    .stack      : {} > RAM (HIGH)        

    .text       : {}>> FLASH | FLASH2    

    .text:_isr  : {} > FLASH             

    .cinit      : {} > FLASH             

    .const      : {} > FLASH

       .cio        : {} > RAM

       .....etc     

 */

#if CRASH_ME

unsigned short whatever[8][8] =

{   {0,    0,    0,    0,    0,    0,    0,    0},

    {0,    1,    0,    0,    0,    0,    0,    0},

    {0,    1,    0,    0,    0,    1,    0,    0},

    {0,    1,    0,    1,    0,    1,    0,    0},

    {0,    1,    0,    1,    0,    1,    0,    1},

    {0,    1,    1,    1,    0,    1,    0,    1},

    {0,    1,    1,    1,    0,    1,    1,    1},

    {0,    1,    1,    1,    1,    1,    1,    1}};

#else

const unsigned short whatever[8][8] =

{   {0,    0,    0,    0,    0,    0,    0,    0},

    {0,    1,    0,    0,    0,    0,    0,    0},

    {0,    1,    0,    0,    0,    1,    0,    0},

    {0,    1,    0,    1,    0,    1,    0,    0},

    {0,    1,    0,    1,    0,    1,    0,    1},

    {0,    1,    1,    1,    0,    1,    0,    1},

    {0,    1,    1,    1,    0,    1,    1,    1},

    {0,    1,    1,    1,    1,    1,    1,    1}};

#endif

int main(void) {

        WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer

        // with CRASH_ME set to 1 the debugger will lock up in the initialisation code and not run to main()

        // with CRASH_ME set to 0 all is fine :-)

        printf("Reference any part of array %d to make the init code fall over\n",whatever[1][1]);

       return 0;

    }

 // ******** END OF EXAMPLE CODE **********

The URL of the which bounces back with over-quota email is http://www-k.ext.ti.com/sc/technical-support/email-tech-support.asp?MCU (which I guess is different for europe and north america) as it bounced back as europesupportdevdsk@dskmail.itg.ti.com

Thank you very much for the compilable test case.  However, I am unable to reproduce the problem.  What are your exact command-line options?  If you can, please cut and paste the output in the build console to this thread.

Below is the build console for a clean build...all the options are the defaults!   One thing to note is that the CCS 5.3 installation has no standard includes (stdio.h) within the directory for 4.1.3 (you can choose to compile with 4.1.0 or 4.1.3) but all the headers are under 4.1.2....

As an aside, if you install CCS5.2 from CD/DVD and run the "updates" tool within CCS is totally breaks the installation (cant find XDS510 for connecting to DSPs, etc) so I ended up having to delete all the CCS installation and reinstall using a download of V5.3 to correct the faulty upgrade patching (I guess this is one for another forum too....)

Just to reitterate...the code appears to compile and link correctly; it will lock up when run on real hardware attached via a debugger (I am using the MSP-FET430UIF).   We are looking at a run time error where the debugger fails to get to main().  If it is single stepped it fails to exit the cinit decompression code...

**** Build of configuration Debug for project TI Array Demo ****

"C:\\ti\\ccsv5\\utils\\bin\\gmake" -k all

'Building file: ../main.c'

'Invoking: MSP430 Compiler'

"C:/ti/ccsv5/tools/compiler/msp430_4.1.3/bin/cl430" -vmspx --abi=eabi -g --include_path="C:/ti/ccsv5/ccs_base/msp430/include" --include_path="C:/Users/user/workspace_v5_2/TI Array Demo" --include_path="C:/ti/ccsv5/tools/compiler/msp430_4.1.2/include" --include_path="C:/ti/ccsv5/tools/compiler/msp430_4.1.3/include" --advice:power=all --define=__MSP430F5435A__ --diag_warning=225 --display_error_number --diag_wrap=off --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU23 --silicon_errata=CPU40 --printf_support=minimal --preproc_with_compile --preproc_dependency="main.pp"  "../main.c"

"../main.c", line 56: remark #1532-D: (ULP 5.3) Detected printf() operation(s). Recommend moving them to RAM during run time or not using as these are processing/power intensive

"../main.c", line 28: remark #1535-D: (ULP 8.1) variable "whatever" is used as a constant. Recommend declaring variable as either 'static const' or 'const'

'Finished building: ../main.c'

' '

'Building target: TI Array Demo.out'

'Invoking: MSP430 Linker'

"C:/ti/ccsv5/tools/compiler/msp430_4.1.3/bin/cl430" -vmspx --abi=eabi -g --advice:power=all --define=__MSP430F5435A__ --diag_warning=225 --display_error_number --diag_wrap=off --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU23 --silicon_errata=CPU40 --printf_support=minimal -z --stack_size=800 -m"TI Array Demo.map" --heap_size=800 --use_hw_mpy=F5 -i"C:/ti/ccsv5/ccs_base/msp430/include" -i"C:/ti/ccsv5/tools/compiler/msp430_4.1.2/lib" -i"C:/Users/user/workspace_v5_2/TI Array Demo" -i"C:/ti/ccsv5/tools/compiler/msp430_4.1.3/lib" -i"C:/ti/ccsv5/tools/compiler/msp430_4.1.3/include" --reread_libs --warn_sections --display_error_number --diag_wrap=off --rom_model -o "TI Array Demo.out"  "./main.obj" -l"C:\ti\ccsv5\tools\compiler\msp430_4.1.2\lib\libc.a" "../lnk_msp430f5435a.cmd"

<Linking>

remark #10371-D: (ULP 1.1) Detected no uses of low power mode state changes using LPMx or _bis_SR_register() or __low_power_mode_x() in this project.

"../lnk_msp430f5435a.cmd", line 172: warning #10374-D: Interrupt vector "RTC" does not have an interrupt handler routine.

remark #10372-D: (ULP 4.1) Detected uninitialized Port A in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.

remark #10372-D: (ULP 4.1) Detected uninitialized Port B in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.

"../lnk_msp430f5435a.cmd", line 173: warning #10374-D: Interrupt vector "PORT2" does not have an interrupt handler routine.

remark #10372-D: (ULP 4.1) Detected uninitialized Port C in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.

"../lnk_msp430f5435a.cmd", line 176: warning #10374-D: Interrupt vector "USCI_B1" does not have an interrupt handler routine.

remark #10372-D: (ULP 4.1) Detected uninitialized Port D in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.

"../lnk_msp430f5435a.cmd", line 177: warning #10374-D: Interrupt vector "USCI_A1" does not have an interrupt handler routine.

remark #10372-D: (ULP 4.1) Detected uninitialized Port E in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.

"../lnk_msp430f5435a.cmd", line 178: warning #10374-D: Interrupt vector "PORT1" does not have an interrupt handler routine.

remark #10372-D: (ULP 4.1) Detected uninitialized Port F in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.

"../lnk_msp430f5435a.cmd", line 179: warning #10374-D: Interrupt vector "TIMER1_A1" does not have an interrupt handler routine.

"../lnk_msp430f5435a.cmd", line 180: warning #10374-D: Interrupt vector "TIMER1_A0" does not have an interrupt handler routine.

"../lnk_msp430f5435a.cmd", line 181: warning #10374-D: Interrupt vector "DMA" does not have an interrupt handler routine.

"../lnk_msp430f5435a.cmd", line 184: warning #10374-D: Interrupt vector "TIMER0_A1" does not have an interrupt handler routine.

"../lnk_msp430f5435a.cmd", line 185: warning #10374-D: Interrupt vector "TIMER0_A0" does not have an interrupt handler routine.

"../lnk_msp430f5435a.cmd", line 186: warning #10374-D: Interrupt vector "ADC12" does not have an interrupt handler routine.

"../lnk_msp430f5435a.cmd", line 187: warning #10374-D: Interrupt vector "USCI_B0" does not have an interrupt handler routine.

'Finished building target: TI Array Demo.out'

"../lnk_msp430f5435a.cmd", line 188: warning #10374-D: Interrupt vector "USCI_A0" does not have an interrupt handler routine.

"../lnk_msp430f5435a.cmd", line 189: warning #10374-D: Interrupt vector "WDT" does not have an interrupt handler routine.

"../lnk_msp430f5435a.cmd", line 190: warning #10374-D: Interrupt vector "TIMER0_B1" does not have an interrupt handler routine.

"../lnk_msp430f5435a.cmd", line 191: warning #10374-D: Interrupt vector "TIMER0_B0" does not have an interrupt handler routine.

"../lnk_msp430f5435a.cmd", line 192: warning #10374-D: Interrupt vector "UNMI" does not have an interrupt handler routine.

"../lnk_msp430f5435a.cmd", line 193: warning #10374-D: Interrupt vector "SYSNMI" does not have an interrupt handler routine.

' '

**** Build Finished ****

Hi Archaeologist,

Good spot - it was the watchdog timing out in the init code!   Looks like someone needs to change all the examples for the MSP430 to setup the watchdog prior to init!   It is also a shame that the debugger (MSP-FET430UIF) doesn't indicate that the 'target reset' or 'watchdog timeout' as either would have made this issue much simpler to locate.

Kind regards,

Tim

I'm very surprised that such a small program would run into the watchdog timeout.  Were the global variables in exceptionally slow memory?  Was the timer set to a very small timeout period?

Hi,

I was supprised this worked too...All the memory is on-chip and it is running from the internal LVO (32kHz).  The watchdog had not been previously configured; we are before the main code, the chip exhibits this behaviour from power up as well as reset.  From memory, the default is many seconds but with the debugger connected this may also include the time to download the code (?)...I guess I can try deliberately causing a watchdog to see what the debugger would do...

We may be looking at some sort of underlying CCS configuration problem but it has been re-installed from the downloaded binary install package twice with cleaning out the C:\TI directory inbetween.  So I am tending to discount this.  My next steps are to setup the CCS 5.3 toolchain on a fresh machine and see if it has the same behaviour.

Any luck your end trying it on some hardware?

Cheers,

Tim