• Locked Locked
  • Replies 9 replies
  • Subscribers 52 subscribers
  • Views 1643 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.

msp430f5438: compiler problem left-shifting uint32_t

Tarak Shah
Prodigy 80 points
Other Parts Discussed in Thread: MSP430F5438A, MSP430WARE

Hi,

For the code:

        unsigned int i;
        uint32_t address = 0x00;


        // compute address, for flash erase/write commands:
        for( i = 1; i < 4; ++i ){
            address *= 256;    // left-shift by 8
            address |= ( (uint32_t)pBuffer[i] );
        }

With no optimizations turned on, for the following snippet of code, w/ pBuffer[1] = 0x01, pBuffer[2] = 0x00, pBuffer[3] = 0x00, the value for address turns out to be 0x00000000 instead of expected 0x00010000.

If i declare address to be volatile, then the value's correct.  Stepping through the debugger, the values for address through the 3 iterations are: 0x00000001, 0x00000100 and 0x00000000.

Not sure if there's some compiler switch that I'm missing...?  Using MSP430F5438A part.

  • TI__Guru**** 244930 points

    I have a rough idea of what may be happening.  Try adding the build option --no_high_level_opt.  Does that help?

    Thanks and regards,

    -George

  • TI__Guru* 84225 points

    I cannot reproduce this without more information.

    What version of the compiler are you using (not the CCS version)?

    What command-line options are you using?

    Could you post a complete, compilable test program which demonstrates the problem?

  • in reply to Archaeologist
    Prodigy 80 points

    Sorry, here's more info.  Recreated a simple function:

    int program_flash ( uint8_t *pBuffer )
    {
        int status;
        unsigned int i;
        uint32_t address = 0x00;
        for( i = 1; i < 4; ++i){
            address *= 256;
            address |= ( (uint32_t) pBuffer[i]);
        }

        address &= (~0x7F); // 128-byte aligned address; segments are 128-byte
                            // aligned at 128-byte boundary

        Flash_segmentErase( __MSP430_BASEADDRESS_FLASH__,
                            (unsigned char *)address );

        status = Flash_eraseVerify( __MSP430_BASEADDRESS_FLASH__,
                            (unsigned char *)address,
                            128);
        return status;
    }

    Complete compiler command-line:

    "C:/ti/ccsv5/tools/compiler/msp430/bin/cl430" -vmspx --abi=coffabi --code_model=large --data_model=large -O0 -g --include_path="C:/ti/ccsv5/ccs_base/msp430/include" --include_path="C:/ti/ccsv5/tools/compiler/msp430/include" --include_path="C:/Users/tshah/perforce/tshah_hwlab12_7200/Branches/5.0/main/Deploy/SW/Source/BoardSupport/msp/G3PowerBoard/bootloader/ccsv5_project/../../application_srcs" --include_path="C:/Users/tshah/perforce/tshah_hwlab12_7200/Branches/5.0/main/Deploy/SW/Source/BoardSupport/msp/G3PowerBoard/bootloader/ccsv5_project/../../../../../../OTSS/texas_instruments/msp430/MSP430ware_1_10_01_18/driverlib/5xx_6xx" --define=__MSP430F5438A__ --diag_warning=225 --display_error_number --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU23 --silicon_errata=CPU40 --printf_support=minimal --preproc_with_compile --preproc_dependency="host_cmd_processor.pp"  "C:/Users/tshah/perforce/tshah_hwlab12_7200/Branches/5.0/main/Deploy/SW/Source/BoardSupport/msp/G3PowerBoard/bootloader/host_cmd_processor.c"
    'Finished building: C:/Users/tshah/perforce/tshah_hwlab12_7200/Branches/5.0/main/Deploy/SW/Source/BoardSupport/msp/G3PowerBoard/bootloader/host_cmd_processor.c'

    Running cl430 on command line:

    MSP430 C/C++ Compiler                   v4.0.0
    Tools Copyright (c) 2003-2011 Texas Instruments Incorporated


    thanks,

  • in reply to Tarak Shah
    TI__Guru* 84225 points

    I'm still not able to reproduce the problem.  Please show the values in pBuffer.

    How are you able to determine that the value of "address" is incorrect?  Are you determining this strictly by looking at the value in the debugger?

  • in reply to George Mock
    Prodigy 80 points

    hi, --define=no_high_level_opt didn't help..

  • in reply to Archaeologist
    Prodigy 80 points

    pBuffer[0] = 0xDD

    pBuffer[1] = 0x10

    pBuffer[2] = 0x00

    pBuffer[3] = 0x00

    The intent is, take 24 bits into a 32-bit value for programming flash at 24-bit addresses for the F5438A part; size_t or uint32_t produce same problem.

    In addition to debugger displaying "address" value, stepping into function shows that the value is still zero and then programming doesn't work at the desired address.  If i declare it "volatile" then the debugger shows right address, stepping into function shows correct value and the flash gets erased (reading back as 0xFF all over the segment).

    thanks,

  • in reply to Tarak Shah
    TI__Guru* 84225 points

    The value of "address" is 0x100000, which has no bits set in the lower 20 bits.  When that value is converted to a 20-bit pointer, it gets truncated to zero, as expected.  Perhaps you meant to initialize pBuffer[1] to 0x01?

  • in reply to Archaeologist
    Prodigy 80 points

    Sorry, typo in my latest posting; I'm using pBuffer[1] = 0x01, results not changed

    thanks

  • in reply to Tarak Shah
    TI__Guru* 84225 points

    I still cannot reproduce the problem.  I need a complete, compilable test case that demonstrates the problem.  I have been unable to construct one with the clues given so far.

    Try turning off hardware multiply support; that is, remove the --use_hw_mpy option.