Workarounds for MSP430 hardware issues
Technical Note 170627
Architectures:
MSP430
Component:
compiler
Updated:
9/8/2017 11:52 AM
Introduction
This Technical Note lists the workarounds for MSP430 hardware issues (Device Erratas) that are implemented in IAR Embedded Workbench for MSP430.
Discussion
Workarounds in the compiler
The following hardware issues have been investigated with respect to the compiler:
CPU4
When --core=430 is given, the compiler will use a safe alternative encoding for PUSH #4/#8.
CPU6
When --hw_workaround=CPU6 is given, the compiler will replace @Rn operands with 0(Rn) unless Rn is PC. The runtime libraries are built with --hw_workaround=CPU6 enabled, but the IDE does not automatically enable this workaround for affected devices.
CPU8
The compiler never generates code that puts odd values into the SP register. It assumes that the value in the SP register is always even.
CPU11, CPU12, CPU13, CPU45
Not handled by the IAR Embedded Workbench for MSP430 toolchain.
CPU15
In situations where a device affected by CPU15 would branch to a different location than an unaffected device, the compiler adds a symbolic value ?CPU15_OFFSET to the branch offset. This value is defined in the linker command files to be either 0 (for unaffected devices), or 2 (for affected devices).
CPU16
The compiler generates code that works on both affected and unaffected devices.
CPU18, CPU19, CPU24, CPU25, CPU27, CPU29
If the option --hw_workaround=nop_after_lpm is given to the compiler, it will automatically issue a NOP after every instruction that might change the LPM bits in the status register SR. The runtime libraries are built with --hw_workaround=nop_after_lpm enabled, and the IDE enables it automatically for all affected devices.
CPU20
The linker command files for affected devices do not allow code in default segments to be placed on the last four bytes of a memory region that is not followed by valid memory. If you modify the address ranges in the linker command file, or add custom segments, you must ensure that this constraint is still met.
CPU21
The compiler never generates POPM #1, SR.
CPU22
The compiler never generates @PC operands, because they are not useful in real applications.
CPU23, CPU34
The compiler never generates instructions that rotate the PC register, because they are not useful in real applications.
CPU26
The compiler never generates CALL SP instructions.
CPU28
The compiler never generates instruction sequences that trigger this issue.
CPU30
In situations where a device affected by CPU30 would branch to a different location than an unaffected device, the compiler adds a symbolic value ?CPU30_OFFSET to the branch offset. This value is defined in the linker command files to be either 0 (for unaffected devices), or 2 (for affected devices).
CPU31
The compiler never generates code that uses the auto-increment mode with a push instruction.
CPU32
The compiler never generates CALLA PC instructions.
CPU33
The compiler never uses negative stack offsets, because they would access the unallocated memory outside the current stack. Such memory can be corrupted at any time by interrupts.
CPU35
The compiler never generates BIT.B @Rx, PC instructions.
CPU39
If --core=430X is given to the compiler, it always places a NOP after any instruction that might disable interrupts.
CPU40
If --hw_workaround=CPU40 is given to the compiler, it will emit a NOP whenever the last instruction in a segment part is a jump instruction. The IDE does this automatically for all affected devices.
Workarounds in the assembler
The following hardware issues have been investigated with respect to the assembler:
CPU4
For the MSP430 architecture (-v0), the assembler uses a safe alternative encoding for PUSH #4/#8 instructions.
CPU6
When -h is given, the assembler gives an error for @Rn operands unless Rn is PC. The runtime libraries are built with -h enabled, but the IDE does not automatically enable this workaround for affected devices.
CPU8
You must take care never to put an odd value into the SP register. Also, the compiler assumes that the value in the SP register is always even. The assembler files in the runtime library never put odd values into the SP register.
CPU11, CPU12, CPU13, CPU45
Not handled by the IAR Embedded Workbench for MSP430 toolchain.
CPU15
In situations where a device affected by CPU15 would branch to a different location than an unaffected device, you can add the symbolic value ?CPU15_OFFSET to the branch offset. This value is defined in the linker command files to be either 0 (for unaffected devices), or 2 (for affected devices). The assembler files in the runtime library use ?CPU15_OFFSET where necessary to work with both affected and unaffected devices.
CPU16
You must take care to write code that works with the chosen target device. In the runtime library, the assembler files have been written to work with both affected and unaffected devices.
CPU18, CPU19, CPU24, CPU25, CPU27, CPU29
If the option --hw_workaround=nop_after_lpm is given to the assembler, it will issue a warning when it detects an instruction that might change the LPM bits in the status register SR, unless it is immediately followed by a NOP. If you are sure that the instruction in question cannot change the LPM bits, you can suppress the warning by placing the assembler directive SUPPRESS_NOP_AFTER_LPM_WARNING on the line just before the line that triggers the warning. The runtime libraries are built with
--hw_workaround=nop_after_lpm enabled, and the IDE enables it automatically for all affected devices.
CPU20
The linker command files for affected devices do not allow code in default segments to be placed in the last four bytes of a memory region that is not followed by valid memory. If you modify the address ranges in the linker command file, or place code in custom segments, you must ensure that this constraint is still met.
CPU21
The instruction POPM #1, SR triggers an error in the assembler.
CPU22
@PC operands are not useful in real applications. You must take care not to write @PC operands in assembler code. In the runtime library, the assembler files do not use @PC operands.
CPU23, CPU34
Instructions that rotate the PC register are not useful in real applications. You must take care not to write instructions that rotate the PC register in assembler code. In the runtime library, the assembler files never rotate the PC register.
CPU26
You must take care not to write CALL SP instructions in assembler code. In the runtime library, the assembler files do not use CALL SP instructions.
CPU28
You must take care not to write instruction sequences that trigger this issue. In the runtime library, the assembler files do not use instruction sequences that trigger this issue.
CPU30
In situations where a device affected by CPU30 would branch to a different location than an unaffected device, you can add the symbolic value ?CPU30_OFFSET to the branch offset. This value is defined in the linker command files to be either 0 (for unaffected devices), or 2 (for affected devices). The assembler files in the runtime library use ?CPU30_OFFSET where necessary to work with both affected and unaffected devices.
CPU31
You must take care not to use auto-increment mode in push instructions in assembler code. In the runtime library, the assembler files do not use auto-increment mode in push instructions.
CPU32
You must take care not to write CALLA PC instructions in assembler code. In the runtime library, the assembler files do not use CALLA PC instructions.
CPU33
Negative stack offsets are not allowed in real applications, because they would access the unallocated memory outside the current stack. Such memory can be corrupted at any time by interrupts. You must take care not to use negative stack offsets in assembler code. In the runtime library, the assembler files do not use negative stack offsets.
CPU35
You must take care not to write BIT.B @Rx, PC instructions in assembler code. In the runtime library, the assembler files do not use BIT.B @Rx, PC instructions.
CPU39
For the MSP430X architecture (-v1), the assembler issues a warning if there is no NOP after any instruction that might disable interrupts. This warning can be suppressed by placing the directive SUPPRESS_NOP_AFTER_DINT_WARNING on the line before the instruction that triggered the warning.
CPU40
For the MSP430X architecture (-v1), the assembler issues a warning whenever the last instruction in a segment part is a jump instruction. If you put data right after a jump inside the same segment part, you must take care to ensure that the data word right after the jump does not trigger CPU40. We recommend putting a NOP after each jump that is followed by a data directive in the same segment part.
Conclusion
See the errata sheet for the device you are using for more detailed information about each Hardware Errata Number(www.ti.com/msp430).
All product names are trademarks or registered trademarks of their respective owners.