• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 53 subscribers
  • Views 2992 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 V5.3 MSP430 compiler run time initialisation lockup!

Tim Good
Prodigy 120 points
Other Parts Discussed in Thread: MSP430WARE, MSP430F5435A

The MSP430 compilter (V4.1.2) within CCS5.3 appears to have a defect in the initialised data area decompression code (it stores initialised globals as compressed constants) and decompresses prior to the execution reaching main.  The defect results in the init code locking up at run time when a non-constant 2D array is used (eg short whatever[8][8]={0,1,2,3,....64}; for example.  Presumably this is in relocating the first index of pointers?  If it is declared as const then works correctly.

This problem can be replicated by including the MSP430ware driverlib (v1.40) and and using any example which includes "MSP430F5xx_6xx/usci_a_uartbauderate.c" .  This results in usci_a_uartbaudrate_UCSx_mod[8][8] being defined by the library which will lock up the taget prior to main().

There is more than one issue here:

(1) why isnt the above symbol defined as CONST within driverlib; as it clearly is!?

(2) why did the compiler testing fail to locate such an obvious defect in initialising the symbol table?

(3) I have tried emailing technical support via the webform but the e-mail keeps bouncing back as apparently their e-mail box is over quota?!!

  • 0
    TI__Guru* 84285 points
    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?
  • 0 in reply to Archaeologist
    Prodigy 120 points

    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

  • 0 in reply to Tim Good
    TI__Guru* 84285 points

    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.

  • 0 in reply to Archaeologist
    Prodigy 120 points

    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 ****

     

  • 0 in reply to Tim Good
    TI__Guru* 84285 points

    I am not able to reproduce this on the simulator.  I'll try to get some hardware to try it on.  In the meantime, please try adding this function to the file and see if that relieves the problem:

    int _system_pre_init(void)
{
     WDTCTL = WDTPW | WDTHOLD;
}
  • 0 in reply to Archaeologist
    Prodigy 120 points

    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

  • 0 in reply to Tim Good
    TI__Guru* 84285 points

    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?

  • 0 in reply to Archaeologist
    Prodigy 120 points

    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