On Tue, Dec 6, 2011 at 8:46 AM, JMGross <msp...@grossibaer.de> wrote:
>
> Hello Wayne,
>
> you correctly detected a possible problem in your code, which from my
> experience really is an exception. Most 'coders' don't
> care for realtime influences and then wonder why the code doesn't work (or
> use a watchdog do reset the CPU when the code
> unexpectedly 'hangs'.
>
> A generic solution to your problem has already beenb pinted out. Set LPM and
> GIE in the same instruction.
> Both, the LPM bits as well as GIE are located in the status register, so it
> comes down to an atomic operation:
> BIS #(LPM4|GIE), R2
>
> In this case, if an interrupt happened before GIE is set and LMP is entered,
> the following will happen:
> GIE/LPM is set.
> LMP is exited, since an ISR is pending. (I'm not sure whether the DCO/XT
> wakeup time does apply in this case)
> the instruction after the BIS is executed (it aslready had been fetched
> before the BIS was executed, hence the usual NOP after an LPM entry)
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.) I know of no
reason why it's necessary to do that after LPM mode settings. What's
your reference for this advice?
> the status register including the GIE and LPM bits is stored on the stack
> GIE ans LPM bits are cleared
> the ISR is executed.
>
> If the ISR doesn't manipulate the stored status register copy on the stack,
> then when exiting the ISR, teh SR is restord and LPM/GIE are
> in effect again.
>
> So if you clear the LPM bits inside the ISR (using the proper 'on_exit'
> macro!), MSP won't return to LPM.
>
> However, your code example has several more flaws.
> - When your ISR does not clear the IFG bit for th einterrupt, the ISR will be
> re-entered as soon as it exits.
> If it does, the port1.ifg.pin1=0 assignment will clear a possible next
> interrupt, and you'll miss it.
Note that clearing IFG is unnecessary if you're using a PxIV register
to determine the interrupt cause. These interrupt vector registers
are not available on older families of MSP430.
> - you enable porti.ie.pin1 in every loop. It stays enabled (unless the ISR
> disables it) and interrupts may
> happen all the time (or after this point) independently of LPM4. You should
> clear GIE on exit of the ISR too,
> so when main is awakened, no further interrupts are handled unless you want
> them again.
If you do this, be aware of the side effects if you have other
interrupt handlers (such as timers or UART activity) that also need to
run. Fundamentally you need to know whether interrupts will be
normally enabled, or normally disabled, and design the control flow of
your program accordingly. Absent other information, my preference is
to have the handler leave GIE unchanged.
> - you check for port1.in-.pin1. But even if an interrupt happened, P1.1 might
> have gone low again in the meantime.
> It's better to set a global flag inside the ISR (don't forget to mark it
> volatile) and check this.
Yes; my example tried to present that solution.
> - depending on the compiler capabilities, the use of bitfields may result in
> less efficient code.
> That's one reason why bitfields for the many registers (especially ports)
> have been removed from the 'official'
> header files.
Well, no, that had no bearing on the decision, at least for mspgcc.
It is true, though, that in many cases code that operates on the
peripheral registers as bytes or words will be at least as good as
code that operates on bitfield overlays of those registers. As JM
points out, it is also easier to see that there are other things going
on in that register if you don't pretend it's a bitfield.
> Especially since every bit operation is a RMW (read-modify-write) operation
> on the whole register
> (which may have side-effects that are easily missed when one jus tlooks on
> the bit oepration).
> Also, since the registers are 'volatile', manipulation of multiple bits in
> the same register results in multiple
> RMW operations. Due to the volatile nature of the registers, the compiler is
> not allowed to group them.
> (the sequential access might be intentional).
>
> If you want to implement a debounce feature, a typical way to do it is to
> start a timer inside the port ISR
> and disable port interrupts (PxIE=0).
> When the timer expires, the tiemr ISR will check for the current port pin
> state, re-enable port interrupts and
> depending on the port pin state will set a global flag and end LPM.
> It gets a bit more tricky if you have multiple interrupt pins, but there have
> been implementations discussed
> and posted in the 'official' MSP forum: e2e.ti.com.
>
> JMGross
>
>
> ----- Ursprüngliche Nachricht -----
> Von: Wayne Uroda
> An: mspgcc-users@lists.sourceforge.net
> Gesendet am: 06 Dez 2011 00:40:59
> Betreff: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt
>
> I have a question which isn't technically related to MSPGCC (more of a msp430
> question) but I thought one of you smart people
> might know.
>
> Imagine the following scenario:
>
> /* 1*/ while (1)
> /* 2*/ {
> /* 3*/ if (!port1.in.pin1)
> /* 4*/ {
> /* 5*/ // Enable interrupt (rising edge) for pin 1.1
> /* 6*/ port1.ies.pin1 = 0;
> /* 7*/ port1.ifg.pin1 = 0;
> /* 8*/ port1.ie.pin1 = 1;
> /* 9*/
> /*10*/ // Enter sleep mode, but only if the pin is still not
> high
> /*11*/ if (!port1.in.pin1)
> /*12*/ {
> /*13*/ LPM4();
> /*14*/ }
> /*15*/ }
> /*16*/
> /*17*/ // Awake
> /*18*/ // Do real work here
> /*19*/ }
>
> The ISR for port1 interrupt just wakes up the processor from LPM4 and clears
> the IFG for pin 1.1.
>
> The problem I see is that there is a small window (between the execution of
> line 11 and line 13) where pin1.1 can go high, have
> the ISR handled and the IFG cleared, and then the system can incorrectly go
> into LPM4 even though pin1.1 is high.
>
> My thoughts are that the only way around this is to avoid using LPM4 and poll
> the state of pin 1.1, which is what I have done in
> previous designs. As far as I know there is no way to atomically enter LPM4
> and enable interrupts so that the pending pin1.1
> IFG can be handled AFTER entering LPM4, thus bringing the system out of LPM4.
>
> Has anybody come up against this? Is using LPM3 the best/only workaround?
>
> I am using 1 family chips, MSP430F148 in particular.
>
> Thanks,
>
> - Wayne
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
