Damn I got schooled, hahaha…
Thanks for pointing this out, otherwise I might have used it and lost hours
debugging…
---------------------------------------
Sergio Campamá
sergiocamp...@gmail.com
On Dec 5, 2011, at 9:22 PM, Eric Decker wrote:
>
>
> 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
