On Mon, Dec 5, 2011 at 4:05 PM, Sergio Campamá <scamp...@ing.puc.cl> wrote:
> Hello Wayne,
>
> The only difference between LPM3 and LPM4 is that the ACLK is stopped in
> LPM4, so moving onto LPM3 won't solve your problem. What is the P1.1
> connected to? If you wanted to wake the system up from LPM4 when there is
> an interrupt on P1.1, you could do this: (I believe that you want to sleep
> only if the pin is down)
>
> void function(){
> P1IES &= BIT1;
> P1IFG &= BIT1;
> P1IE |= BIT1;
>
>
> while(1){
> sleep_if_down()
> //do work
> }
> }
>
> __attribute__((critical)) void sleep_if_down(){
> if(! P1IN && BIT1){
> LPM4();
> }
> }
>
> interrupt(PORT1_VECTOR) PORT1_ISR(){
> //wake up from LPM4
> P1IFG &= BIT1;
> _BIC_SR_IRQ(LPM4_bits);
> }
>
> What this does is that it checks if the P1.1 is down, if it is, it enters
> LPM4. Now, the __attribute__((critical)) part tells the compiler (I learned
> this in this mailing-list) to disable interrupts while in the function. So
> you won't handle the interrupt until after the comparison is made.
>
Have you looked explicitly at the code generated for the above?
If I understand critical correctly, it basically disables interrupts
during the routine. Which means that when you go asleep (LPM4)
interrupts will be disabled and the cpu goes away forever because it can't
take the Port1 interrupt.
I believe you have to have interrupts enabled when you do the LPM4. Which
gets back to Wayne's critical region/race condition issue.
eric
> You don't have to setup the IE and IES all the time, just the first time,
> that's why I took it out of the while, and the IFG gets cleared in the
> interrupt vector, no need to do it again.
>
> I hope this helps. Best regards,
> ---------------------------------------
> Sergio Campamá
> sergiocamp...@gmail.com
>
>
>
>
> On Dec 5, 2011, at 8:40 PM, Wayne Uroda wrote:
>
> > 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
------------------------------------------------------------------------------
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
