Program execution stops when a variable is declared in IRQ handler

[oversc0re]

Posted on December 06, 2016 at 22:28

Hello!

I've come across this strange problem where I can't seem to find a reasonable explanation why it occurs:

I am using a simple RTOS, I have an EXTI interrupt handler that calls a simple function which sets a flag and returns.

If I declare a local int variable inside that function, the program execution stops. It does not hardfault, it just stops. OS scheduler does not work anymore, the code actually never returns from the function, everything freezes until watchdog kicks in.

Irq handler is very simple:

void EXTI9_5_IRQHandler(void)

{CoEnterISR();EXTI_ClearITPendingBit(EXTI_Line6);debug('XTI9_5 handler\n');xSensor_IRQ_callback();CoExitISR();}

The function as well:

void xSensor_IRQ_callback()

{   u32 status = xSensor_geStatus();   if ((status & XS_MSTAT_IRQSRC) == XS_IRQSRC_RX)   {      rx_len = status >> 8;      debug('RX %d\n', rx_len);   } else   {      if(initialized)      {         isr_SetFlag(xs_irqMeas);      }

   }

}

The code above never returns. As soon as I declare status variable globally, everything works. 

If I don't store the result of xSensor_getStatus() in a variable and call the function whenever it is needed, the code also works as it should. As soon as I add a simple declatation such as

u32 status = 1234;

which is not used anywhere below, the program stops again. 

Any suggestions what may be leading to such behavior or where should I look into would be warmly welcome. 

Regards,

over.

[Tesla DeLorean]

Posted on December 07, 2016 at 10:23

Hard to say, I'd first look at the stack allocations, and a disassembly of the code. Might look at the static initialization code.

If you stop in the debugger where is it stuck?

[Jeroen3]

Posted on December 07, 2016 at 11:38

Put this in your init somewhere. It'll catch your hardfault. Which you probably have.

CoreDebug->DEMCR |= CoreDebug_DEMCR_VC_HARDERR_Msk;

Then, in the hardfault. Look at SCB->CFSR, to see which fault is active.

I think this is available in at least m0 to m4.

[Walid FTITI_O]

Posted on December 07, 2016 at 12:00

Hi

sc0re.Over

,

The variable exceed the available stack space, causing a stack crash. Try to increase the stack space. The best practice such 32 bit status

variable

should be declared as global and allocated inthe heap.

Ifthe response is useful, you would mention that by clicking the correct button. Thank you for the contribution

-Walid F-

[aaron239955_stm1_st]

Posted on December 07, 2016 at 20:19

I might guess that the label 'status' is very common and you may be writing over an important global variable used somewhere else in the system (maybe even in your OS kernel...)

Try changing the variable name to something less likely to collide with anything like StatuS, Status1, DeviceStatus, etc.

[oversc0re]

Posted on December 07, 2016 at 21:03

Thanx for all for the inputs. Some brief comments are below:

- I played with the debugger a bit. The status variable is stored directly in R0, everything seemed to be in order, but the debugger froze when the stack was pulled while leaving the function. I didn't have enough time time to play with it some more.

- I am already printing the debug info on hardfault, but in this case, hardfault does not occur. The execution simply stops. 

- The stack overflow seem plausible although status value is stored directly in R0. I will try increasing stack size. 

- No, I am not overriding other variables and afaik you can easily override a global variable with a local one.

I'll post here when I find the time for some more testing.

Regards,

over. 

[Tesla DeLorean]

Posted on December 07, 2016 at 20:45

I don't know, I'd try to avoid variable names with global scope and the potential to clash in the name space, doesn't scale well and generally clutters things up. To localize within the bracketed scope using the static directive.

As coded the optimize could choose to hold the value in a register, and not use the stack or memory directly or at all depending on the surrounding code.

Walid FTITI wrote:

If the response is useful, you would mention that by clicking the correct bottom. Thank you for the contribution

Also I think you want them pressing your button not your bottom. Is that a fixed signature, or one you paste into each post?

[Jeroen3]

Posted on December 08, 2016 at 07:31

Local scope names have priority over global scope names. This should not cause an issue if the compiler follows the standard.

[Walid FTITI_O]

Posted on December 08, 2016 at 10:35

Hi Clive, 

It is just a copy/paste statement. I've submited a request to add a signature feature.

I keep you informed for any update.

-Walid F-