----- Ursprüngliche Nachricht -----
Von: Peter Bigot
Gesendet am: 08 Dez 2011 19:11:57
On Thu, Dec 8, 2011 at 6:43 AM, JMGross <msp...@grossibaer.de> wrote:
>> 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.
Breakpoints are hit when an instruction fetch is executed on the BPs address.
Which happens in the last cycle of the BIC instruction (because
the BIC target is a register and doesn't allocate the bus for the writeback.
So the breakpoint is hit the moment the BIC is executed. Before the ISR
has been called that would end LPM again.
>> 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.
_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.
It the ISR doesn't end LPM, then of course this instruction is not
executed again next time. The 'pending' instruction then is the RETI, whcih
does not complete ebcause after fetching SR form the stack, LPM is active
and the following return address fetch is not executed until the next interrupt
comes. (RETI stops in the middle of its execution).
> 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.
Yes. but it is executed _before_ the waking ISR is entered.
In most cases, this won't make a difference, but in some cases...
> Good; I was worried there for a while, as that would be a huge issue.
Maybe not as huge as you originally thought, but still:
If an LPM enter is followed immediately by a GIE clear,
and the ISR that is called next does not end LPM,
this was the last call to an ISR ever.
Always having a NOP after BIS_SR or BIC_SR (and friends)
will work around it, but many people arenot aware of this.
I don't think that all versions of CCS always did add a NOP.
problems reported in the forum indicate that at least earlier
versions of CCS (and on this price, who does always update
to the latest version if one has a full license?) it was an issue.
In these cases, adding a NOP manually did help.
Also most demo code still contain the NOP. Usually with the
misleading comment 'for debugger', which seems to imply that you
shall place a breakpoint there. But no, you have to place the
breakpoint on the next instruction after the NOP.
JMGross
------------------------------------------------------------------------------
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
