On Mon, Dec 12, 2011 at 7:49 AM, JMGross <msp...@grossibaer.de> wrote: > > ----- Ursprüngliche Nachricht ----- > Von: Peter Bigot > Gesendet am: 09 Dez 2011 16:45:44 > >>>> _executed_ is a different thing. The instruction is fetched (and a >>>> breakpoint >>>> on it is triggered) on every MSP. >>>> However, the instruction will be _executed_ the moment an interrupt is >>>> triggered and LMP ends. However, it will be executed before the ISR >>>> is entered, and not, as one would expect, after the ISR has ended LPM. > >>> I could believe this, but please provide a reference supporting your claim. > >> The claim is not supported by a test program using an MSP430G2553. >> With this sequence: >> 2c: 32 d0 f8 00 bis #248, r2 ;#0x00f8 >> 30: 16 43 mov #1, r6 ;r3 As==01 >> where r6 was previously zero, r6 still has the value zero within the >> interrupt handler that wakes the MCU. This is entering LPM4; LPM0 >> behaves the same. > >> Have I misunderstood what you're saying? Is there a different >> situation that you meant? > > No, you got it right. The G series seems to be immune. (See my other > post). So TI did some change in the silicon. I don't know when > and where. > I only know that the code above would have exposed the problem > on the 1232 I worked on ~6 years ago. > (interestingly, this never appeared in the 1232 errata sheet) > Since then, all my operations on SR include a following NOP unless > the next operation is known to be not critical. So I never checked > again. > And I don't have one of the old 1232 anymore. > However, on many MSPs (if not all), a breakpoint on the MOV would > be triggered before LPM is entered. > Maybe the LMP mechanism does discard the already fetched > instruction then.
Thanks. As I've said, I don't consider the evidence of a breakpoint firing prior to LPM to be relevant to anything. The instruction would have to be re-fetched after wakeup anyway, given intervening interrupt processing. As you note, there are no CPU errata (per the April 2011 update) for the MSP430F1232 that would explain the behavior you remember. To summarize, in the absence of CPU errata, we have no evidence that the MSP430 architecture allows code following an instruction that enters LPM to be executed before entering LPM, or before the instructions in an interrupt handler entered from LPM, or at any other point before the CPU resumes normal execution. Any other behavior may be considered a silicon bug. There are several CPU errata, possibly related to partial execution, that are avoided by adding a NOP including CPU18, CPU19, and CPU27, but the problematic contexts are pretty unusual. The compiler should implement the workaround without user code needing to insert NOPs. One of my TI contacts is preparing a list of the problems that the compiler will need to work around, and I may be able to address them in some upcoming peephole optimization work. Peter ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
