On Thu, Dec 8, 2011 at 6:43 AM, JMGross <msp...@grossibaer.de> wrote: > > ----- Ursprüngliche Nachricht ----- > Von: Peter Bigot > Gesendet am: 06 Dez 2011 17:15:18 >> There's normally a no-op after disabling interrupts because of the >> chance that the following instruction should have been protected from >> interrupts, but that the disable would not occur in time due to >> pipelining. (The __disable_interrupt intrinsic does this for you, at >> least with IAR (second-hand) and mspgcc (first-hand) since it can't >> guarantee what instruction will immediately follow.) > > IIRC, CCS doesn't.
My contact at TI confirms that CCS does do this, making IAR, CCS, and mspgcc consistent. > Nor do the BIC/BIS intrinsics which many people use, > either for combining GIE and LPM set, or even just for setting GIE. >>> I know of no >>> reason why it's necessary to do that after LPM mode settings. What's >>> your reference for this advice? > > Logical thinking and experience. > many people set a breakpoint on the next instruction, expectign it hit after > LPM was entered and ended by an ISR, but it is hit right before the LPM > was entered at all. This could easily be due to the debug infrastructure. It's not obvious that this is relevant to how the MCU executes instructions when not being traced/single-stepped. > Also, like with GIE, the instruction after the BIS will be executed before > the ISR is entered. And if it is an instruction that assumes the ISR has > happened (e.g. set a global flag), or that the ISR triggering event > has already occurred, you're hosed. I am informed that silicon subject to erratum CPU18 is vulnerable to having the instruction following LPM flag sets be executed before LPM is entered, and that the CCS compiler will generate a NOP after BIS SR to compensate. The chips that are listed in the msp430mcu devices table as having this bug are the F54xx non-A versions (e.g., MSP430F5438, but not MSP430F5438A), and most of the CC430 chips. Absent silicon bugs, it seems safe to say that LPM is entered before the following instruction is executed, and that it is not generally necessary to follow LPM updates with __no_operation(). Though I suppose doing so doesn't hurt except for taking up ROM. Good; I was worried there for a while, as that would be a huge issue. Once I have full details confirmed including whether the same bug applies under a different number to other families, I'll enter a trac ticket to work around the problem in the necessary situations. At the moment, I believe the only silicon erratum handled by the mspgcc toolchain is the venerable CPU4 (push #4 or #8), which is assumed to apply to any pre-CPUX MCU. Peter ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
