• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 78 subscribers
  • Views 1236 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.

MSP430F2132 Errata, CPUOFF

PeterETT
Prodigy 115 points

Hello,
I have some questions regarding the MSP430F21x2 Device Erratasheet, SLAZ041C–March 2008–Revised January 2010
and the bug CPU19 CPU Module: CPUOFF can change register values.

The errata says:
If a CPUOFF command is followed by an instruction with an indirect addressed operand
(for example, mov @R8, R9, and RET), an unintentional register-read operation can
occur during the wakeup of the CPU. If the unintentional read occurs to a read-sensitive
register (for example, UCB0RXBUF or TAIV), which changes its value or the value of
other registers (IFGs), the bug leads to lost interrupts or wrong register read values.

First: what exactly is an CPUOFF command? Is it any instruction setting or clearing the CPUOFF bit in the status register?

Second: if I enter LPM3 in the main loop, and then wakes up by an interrupt. Which instruction is defined to follow the CPUOFF command? Is it the first instruction after the LPM3 command in the main loop or is it the first instruction in the ISR?

 

/Peter

  • 0
    Guru 227245 points

    PeterETT said:
    what exactly is an CPUOFF command? Is it any instruction setting or clearing the CPUOFF bit in the status register?

    Yes. Any command that sets the CPUOFF bit (or rather the fact that the CPUOFF bit is set) triggers this erratum.

    PeterETT said:
    if I enter LPM3 in the main loop, and then wakes up by an interrupt. Which instruction is defined to follow the CPUOFF command? Is it the first instruction after the LPM3 command in the main loop or is it the first instruction in the ISR?

    That's the reason of this problem: when the CPUOFF bit is set (so the target of the operation is the status register and no memory address), the next instruction is fetched from flash simultaneously (pipelining). Then MCLK stops, while the next isntruction has been already fetched.
    If this next instruction is an indirect memory read (that means, the address of the memory access does not need to be fetched from flash first, but is determined by a register value), then there might be an unintentional read from this source location before the ISR kicks in. If this address is a hardware module register with side-effects (e.g. a read clears interrupt flags), these side-effects will also kick in while the instruction itself isn't executed at all. It rather will be executed in a whole when the low power mdoe is ended inside the ISR and normal operation of hte main code is resumed.

    Easiest workaround is to place a NOP right behind any instruction that sets the CPUOFF bit.

    BTW: for the same reason you shouldn't set  abreakpoint on the command immediately following a CPUOFF. The breakpoint is triggered when teh instruciton is fetched, and this happens immediately, before the low power mode is entered, even if the instruction would be executed after LPM has been ended.

**Attention** This is a public forum