On Tue, Apr 17, 2012 at 2:53 AM, Wayne Uroda <[email protected]> wrote: > Hi, > > I feel quite foolish asking the following question... Please don't judge me > too harshly... > > In my MSPGCC based system I have got the following #defines which I use for > critical (interrupts disabled) access around volatile memory which is > modified by interrupt routines: > > #define criticalStart() __asm__ __volatile__("push r2"::); __asm__ > __volatile__("dint"::) > #define criticalEnd() __asm__ __volatile__("pop r2"::) > > Usually I use this code to write to a counter which is decremented by my > timer ISR, eg > > void setTimeout(UInt16 timeout) > { > // Other work before setting the volatile, ISR driven value > criticalStart(); > busyTimeout = timeout; > criticalEnd(); > } > > Today I am using Code composer for a new project and I tried a similar trick. > After several hours of debugging, it turns out that my little "push r2" trick > causes code composer to access local variables incorrectly, since these are > accessed relative to the stack pointer. > > For example, the following code does not function correctly because the > "localTimer" variable is not written correctly (the memory access is one word > off owing to the extra stack push). > > while(true) > { > UInt32 localTimer; > criticalStart(); > localTimer = globalTimer; > criticalEnd(); > if (localTimer == 0) > { > break; > } > } > > > My question is, does GCC analyse the inline assembly code and notice that I > have altered the stack, or have I just been *extremely* lucky for many years? > Certainly code composer does not see that I have modified the stack. > > I am going to change my critical macros like so (this is how I am now doing > critical access in code composer, which, unless I am missing something, has > no builtin way to do critical functions): > > #define criticalStart() { UInt16 __oldInterruptStatus__ = READ_SR(); __asm__ > __volatile__("dint"::) > #define criticalEnd() WRITE_SR(__oldInterruptStatus__); } > > Any major issues with doing this? Should I instead wrap all reads and writes > to volatile memory/variables with critical functions? I usually only wrap one > line of code with the critical macros. > > Also if anybody knows code composer v3.1 and knows a better way, please let > me know.
You would be better off using the intrinsics to save and restore the interrupt state, and to manage interrupts. Among other things, the intrinsic works around the issue where dint doesn't protect the immediately following instruction from being interrupted by also emitting a following "nop": the asm instruction won't do that. These intrinsics should be available in (current) CCS, IAR, and gcc, though it may be the first two spell their names differently. A detailed example is the launchpad PWM demonstration in the test430 repository: see http://mspgcc.git.sourceforge.net/git/gitweb.cgi?p=mspgcc/test430;a=blob;f=demos/launchpad/pwm/pwm.c 116 { 117 __istate_t istate = __get_interrupt_state(); 118 __disable_interrupt(); 119 if (pwm_ == pwm) { 120 PWM_CCTL &= ~(TAIE | TAIFG); 121 PWM_PxOUT &= ~pwm_->pin_mask[0]; 122 pwm_ = NULL; 123 } 124 __set_interrupt_state(istate); 125 } Look at the <intrinsics.h> header from msp430mcu, in your standard mspgcc include area, for documentation on available intrinsics. Peter > Thanks, > > > - Wayne > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
