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.

MSP430F5327 Errata

Genius 5960 points
Other Parts Discussed in Thread: MSP430F5327


Please tell us about Eratta of MSP430F5327.

Errata number:

CPU26 / CPU27 / CPU28 / CPU29 / CPU30
CPU31 / CPU32 / CPU33 / CPU34 / CPU35

Above Errata is, we believe that there is a corresponding propriety by the compiler version.

My customers are using the MSP430 Compiler Tools version 4.2.1, but do you have been the measures?

Best Regards,


  • Hi Hamada!

    What is your question in detail? Do you want to know if all those CPU-related issues mentioned in here

    behave different when using different compiler versions?


  • Hi,

    Thank you for reply.

    I'm sorry.

    My customers are making a product using the "MSP430 Compiler Tools version 4.2.1".

    I would like to know

    "MSP430 Compiler Tools version 4.2,1" whether are measures of Workaroud below Errata?

    (CPU26 / CPU27 / CPU28 / CPU29 / CPU30/CPU31 / CPU32 / CPU33 / CPU34 / CPU35/CPU40)

    Best Regards,

  • Hi Hamada,

    A careful reading of the errata document that Dennis linked will tell you which ones can be handled in the compiler or not. Not all CPU bugs can be worked-around in the compiler, and not all CPU bugs are something that the compiler would ever generate and so then don't apply in C.

    For example: Look at CPU27 - this one makes no mention of the compiler, and it is not worked around by the compiler. You as a user could avoid that erratum by not using nested interrupts (don't set GIE during an ISR) but it's not something the compiler will do - there's no mention of the compiler in the errata/workaround text.
    For another example, look at CPU31 - the workaround here says "The compiler will not generate a PUSHX.A instruction that involves the SP" So that means if you're writing in C, you don't have to worry about this one because it will never generate the assembly that would cause the issue anyway. Does this help?

    One more useful thing is that you can in CCSv6 go to Project > Properties > Build > Advanced Options > Runtime Model Options and see some boxes for working around some errata or not. You can see CPU40 here for example (and in the CPU40 text in the errata doc you can see it is mentioned as being worked around by the compiler). You can check this with your chosen compiler version to check if the workaround is included.


**Attention** This is a public forum