Learning Interrupts

[Hanghae 0]

I am learning MSP430 programming with the tutorial at http://mspsci.blogspot.com/2010/07/tutorial-01-getting-started.html. I had trouble getting one of the first interrupt-driven programs to work, so I debugged it by adding a write to a RAM location to the interrupt service routine. Then I could see (by printing out that location with mspdebug) whether the ISR was ever entered. Indeed, the reason that program did not seem to run at all was precisely that the ISR was not entered.

 

Now I have progressed to CMeterG2211.c and wanted to use the same trick (if it can be called that). There are three ISR's and, correspondingly, I added three global variables at the start of the C file, like this:

unsigned char mark1 = 0;
unsigned char mark2 = 0;
unsigned char mark3 = 0;

I also added something like this

 mark1++;

at the start of each ISR.

 

Now, the program worked almost out of the box, and there has been no particular need to debug it. However, out of curiosity, I checked the markx variables after a successful run and found them all to be 0 (zero). How can that be? The fact that the program runs OK must indicate that all the ISR's are entered at least once, so how can the variables still be zero?

 

[terjeio 134]

It is most likely due to the optimizer interfering...

 

Global variables in an ISR should be marked as volatile to avoid that:

unsigned volatile char mark1 = 0;

Terje

[Hanghae 0]

It is most likely due to the optimizer interfering...

 

Global variables in an ISR should be marked as volatile to avoid that:

unsigned volatile char mark1 = 0;

Terje

Thank you, but no - adding volatile does not change the behavior.

[enl 227]

My first thought would be to agree about the use of volatile. External variables should be treated as volatile by default, but not all compilers do.

 

My next thought would be that a reset is being done before you are looking at the values. Can you watch the vlue during operation?

[Hanghae 0]

 

My first thought would be to agree about the use of volatile. External variables should be treated as volatile by default, but not all compilers do.

 

My next thought would be that a reset is being done before you are looking at the values. Can you watch the vlue during operation?

 

 

 

No, I am not familiar enough with the debugger, at least not yet.

 

The program sits in an infinite loop waiting for interrupts. First, it is the button that starts the measurement. Then, it is overflows from TIMER0 while the capacitor is charged. Last, the interrupt is from TIMER1 when the capacitor voltage falls to 0.25VREF. Then the loop restarts - there does not seem to be a reset.