Stack Overflow for MSP430FG4618

Hi Vincent,

you can use as many interrupts as you want, even nested ones (you need to take extra care in this case).

Do you know that you can increase your stack size? Which IDE are you using? In CCS you can do it by clicking on your project properties; the screenshot shows you were to find it (MSP430F2274 in this example).

Rgds
aBUGSworstnightmare

Thanks. I have increase the stack size. But the situation still occurs. I am wondering under what conditions will the MSP430FG4618 reset.

Thanks... 

Hi Vincent,

seems you will have to sit down and analyse your software a litte further.

Rgds
aBUGSworstnightmare

First, increasing the stack size has no impact on the code. It is nothing more than a threshold settign that causes a linker error if there isn't at least this much ram left after placing the variables. Changing it does not change a single code bit, nor does it change the code execution. Besides triggering a linker error, the only othe reffect may be that  the debugger will maybe issue a warning if the stack grows larger than that.

If your code generates a stack overflow, it will do so, independently of this setting.

I tis not necessary to clear teh GIE bit on each ISR. It is automatically cleared by hardware when entering an ISR. So normally, an ISR cannot be interrupted by another one. (NMIs are the only exception, and a reset, if you count it as an ISR)

If you set GIE, however, to allow nested interrupts, you may only do so after removing the cause of the interrupt. Else the interrupt is still pending and the ISR will be interrupted by itself immediately. And again. And again. Until the stack overflows.
So you MUST somehow clear the IFG bit that was the cause of the interrupt before you may set GIE and allow other ISR interrupting you. There are usually more than one way to do it: manually clearing the IFG bit, reading/writing the input/output buffer that is full/empty etc.

An exception are some of the timer interrupts. Since there is only one interrupt source for the CCR0 interrupt, it is automatically cleared when the ISR is entered. The interrupt section of the module description will tell you what to do to clear the IFG.

Vincent Fung said:

I am wondering under what conditions will the MSP430FG4618 reset

Hello Jens-Michael,

Your suggestion seems to be the one of the reasons for stack overflow. In fact, I have cleared the port 1 IFG and port 2 IFG once they have been set. Do I need to clear the flag created by basic timer, timer A, timer B and ADC as well??

Thanks...

Vincent Fung said:

Do I need to clear the flag created by basic timer, timer A, timer B and ADC as well??

For the timers, well, the CCR0 interrupt is auto-clearing on ISR entry. for The other vectors, I don't know. Since 1611, there is an interrupt vector register which when read clears the IFG that is associated the the IV register reading (e.g. your read '12' and '12' is the vector address for tiemr overflow, then the OVIFG bit has been cleared throught his read. There may be still other IFGs set for this timer and if you set GIE, another itnerrupt is generated and the ISR is executed a second time, this time giving a different IV reading (and clearign the next bit).

Since the IV readings are presented in order of priority, setting GIE too soon wil invert the priority. I fyou use severa interrupt sources in the same vector, it might be an idea to jsu tllop back to readinf the IV register at the end of your ISR and handle the next interrupt cause withotu leaving the ISR. It saves some cycles (including LPM wakeup time etc.). You may not, of course, enable GIE in this case. Jus tcontinue looping through the ISR until IV reads zero. Then exit the ISR.

The interrupt section of the timer description should tell you the proper handling of the individual IFG bits and when they are reset.

I am trying to prevent the MSP430 from reset. I notice that when I reduce the program code size by deleting one to two functions for the device, the reset situation disappeared. Initially, I thought that it is related to those codes that I have deleted. However, I found that the reset disappeared no matter which functions I deleted. Reset will be disappeared no matter which part I have deleted.

I would like to know if the MCU needed to handle too much, what will be the behavior of it Will it run in a crazy way like in my case??

Thanks 

The following method may be able to find if stack overflow was the cause of reset.

a) Use FET to debug your code.

b) Set up a single break-point at the beginning of your code, or at the beginning of c start-up code if you are using c.

c) Set up a memory view window to show the RAM where the stack will grow into. Click the Reset icon on the debugger screen. The debugger will fill that area of RAM with 0xCD.

d) Now start to run your code. If it resets, the break-point should catch it. Examine the RAM. If not all the 0xCD's are changed, then you did not have stack overflow.

--OCY

Thanks OCY,

I have tried with your suggested procedure, all the 0xCD are changed, and according to your description, it is likely that I have the stack overflow.

But the situation is that I do not get this problem once I delete one to two functions for the device. I would like to know does it mean that I have written too much to the MSP430. Can I do anything to solve the stack overflow apart from deleting one to two functions from my device??

In fact, I have double checked that there should not be any variables that will grow to infinity in my program.

Thanks.

If you increase the stack size, the Debugger will put more 0xCD's in RAM. This will not help you to solve the problem, but you will be able to see more RAM being trashed when you examine them.

The intended usage of the stack are:
(a) Stores the return address of a CALL. This should be release by the routine being called when it returns.
(b) Stores the parameters of the CALL. This should be released by the caller after the call returns.
(c) Stores the SR and the PC when an interrupt is granted. This should be released by the ISR.
(d) Stores temporary data during the execution of a routine or ISR. This should be released by the same routine or ISR that stores them.

At any point in time, the stack contains the aggregation of all the yet un-release storage of all the above. If you examine the former stack area after an unexpected reset, you may be able to spot remnants of (a) as they always point to the address of the next instruction after a CALL instruction in your code. You may be able to spot remains of (c) too, as SR must have 0s at BIT-15 to BIT-9 and PC must point to an interruptible instruction of your code. These only provide clues to what happened and is very hard detective work. Misbehaving code, especially after it crashes, could also put trash in RAM and make it more difficult.

BTW. You said if you deleted one or two functions your code will not reset itself. I suggest you examine the RAM the same way to see how much RAM is used by the stack. I suspect that it is already excessive. Excessive stacking is usually caused by too many layers of nested CALL (a), too many aggregated parameters (b) in these nested CALL, or too many aggregated temporary storage (d) in these nested CALL. Do you have recursive CALL? If so, they "nest" easily. The remnants of former stack area is much easier to understand before the code crashes.

On some MSPs (depending on the internal debugging module) it should be possible to set a breakpoint onto access of a memory location. it could be set to the bottom of the allowed stack area. So the moment the stack overflows into the data area, you should get a break and can examine where in the code you are and where it comes from.

Removing code from the project should not affect stack usage if these functions were never called. It may, however, alter the position of the rest of the code in flash. This includes functions being put into the upper flash area (if any) and such.
Maybe the system still runs wild, but does just not cause a reset anymore because the code rampages in different locations than with more program code.

Hi!

How is this done in assembly?

Jose Orellano said:

How is this done in assembly?

How is what done? Reserving stack space? Since the stack space reservation is a feature of the linker, it is independent of the language used. It just allocates some space on ram, so less is available for use in whatever language you use.
It does not, however, limit the stack by any means. It just reserves some space that is for sure not used for anything else.