Workarounds for MSP430 hardware issues

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.