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.

MSP430I2021: Code size optimization to fit into flash

Part Number: MSP430I2021

Hi team, 

My customer needs every possible option from the compiler to optimize the code size to fit into the FLASH. However they are running into some problems: 

There is the option for the silicon version:

In SLAU131R they found:

1. But is the MSP430i2021 an MSP430x device or not?

1a. If not, is there a problem to activate it anyway?

The code size reduction is significant for my customer. A compiler warning is not generated.

2. Is it ok for them to use this option without any drawback?

Also, there is an option for the hardware multiply: 

The MSP430i2021 has a 16 Bit hardware multiplier. If they set the optimization to 32 there is no compiler warning and the code is significantly reduced.

Their customer wants this option set to 32 to reduce the code size.

3. Is this a feasible way?

Thanks for the support.

Obinna.  

 

  • Obinna Ezeilo said:
    1. But is the MSP430i2021 an MSP430x device or not?

    The MSP430i2021 has a MSP, not MSPX CPU.

    Obinna Ezeilo said:
    1a. If not, is there a problem to activate it anyway?

    The code size reduction is significant for my customer. A compiler warning is not generated.

    The MSP430 compiler doesn't generate a warning if the selection of the processor options doesn't match the target device, but if the compiler is told to generate instructions for a MSPX CPU but the actual device has a MSP CPU the program won't run as the MSP CPU won't understand the MSPX instructions.

    As an example, took a program for a device with a MSP CPU, but set the --silicon_version compiler option to mspx. The resulting program crashed in the compiler run-time startup code before main() was reached.

    Obinna Ezeilo said:
    The MSP430i2021 has a 16 Bit hardware multiplier. If they set the optimization to 32 there is no compiler warning and the code is significantly reduced.

    As above, the compiler won't warn if the --use_hw_mpy option doesn't match the target device.

    Obinna Ezeilo said:
    3. Is this a feasible way?

    No. As an example took a program for a device with a 16 bit hardware multiplier.

    When the --use_hw_mpy option was changed from 16 to 32 the 16x16 multiplies still produced the correct results, but 32x32 multiplies then produced incorrect results.

  • Hello Obinna,

    Just clearing out older threads, but Chester is correct.  The compiler has no way of knowing what the end target is going to unless we indicate it.  If we tell it to build for different hardware, it will effect the code in size, but won't be built for the correct hardware.  

    Thanks,

    JD

**Attention** This is a public forum