Thanks for the discussion - I apologise for my code sample having flaws, it isn't production code just something I threw together to illustrate the point. In my case I am only interested in the level of the pin (sleep when it is low, awake when it is high) and so I am not concerned with missing edges other than the critical edge which brings me out of LPM4. I am aware that I still need to be careful of the order in which I enable the interrupt/clear the ifg and disable interrupts before finally checking the level of the pin and entering LPM4 if appropriate. One thing that I have never done is use the on_exit macro - I use the wakeup keyword instead - I'm guessing there are potential problems with the wakeup keyword?
- Wayne -----Original Message----- From: JMGross [mailto:msp...@grossibaer.de] Sent: Wednesday, 7 December 2011 12:47 AM To: MSPGCC mailing list, Subject: Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt 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) 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. - 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. - 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. - 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. 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
