----- Ursprüngliche Nachricht -----
Von: Peter Bigot
Gesendet am: 09 Dez 2011 16:13:48
On Fri, Dec 9, 2011 at 8:49 AM, JMGross <msp...@grossibaer.de> wrote:
>>>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.
>> _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.
I discovered this problem several years (~6) ago on the 1232. I don't have
the code for reproducing it anymore. And maybe it has been fixed
on newer silicon. Since I have the workaround (NOP) in all my code,
I never tested again.
However, I just wrote something that should have reproduced it on the
G2231 (the only MSP I have on my desk right now for experiments)
and I was unable to reproduce it:
volatile int loop;
int main(void){
P1DIR = BIT0|BIT6;
P1OUT=0;
TA0CTL = MC_2|TACLR|TAIE|ID_3|TASSEL_2|TAIFG; // force IRQ
_BIS_SR(LPM0_bits|GIE);
_BIC_SR(GIE);
while(1)
{
P1OUT ^= BIT6;
for(loop=50000;loop;loop++) _NOP();
};
}
interrupt(TIMERA1_VECTOR) isr (void)
{
P1OUT ^= BIT0;
TA0CTL &= ~TAIFG;
}
With this code, the red LaunchPad LED (P1.0) is blinking,
so the BIC is never executed (with or without the TAIFG preset).
As soon as I have a non-A 5438 on the desk, I'll try it with this one.
(I'm currently working on software, not on hardware :( )
Anyway, CPU18 is not about messing up a CALL instruction
following the BIS. Not about executing the instruction before
LPM is exited again. Adding your information, it seems that
CPU18 is actually messing up the CALL instruction
by partial execution, while other instructions may be completely
executed prematurely.
however, CPU24 and CPU27 and maybe some more are related
to this topic too.
P.s.: on MSPGCC 3.2.3, the BIC_SR and BIS_SR do not add a NOP.
Nor do __disable_interrupt() etc.
JMGross
------------------------------------------------------------------------------
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
