Weird Stack problem - Concerto M3

Wil P.

The first time that I enter a timer based interrupt it seems like I have a large stack. The interrupt is the Task1ms and my breakpoint is at the top of the function:

Here is the memory view:

This function is a timer based task (1ms) that is called when Timer A timeouts; this is all configured in InitTImers function:

	//	Timer 2 = 1ms
	SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER2);

	TimerConfigure	(TIMER2_BASE,TIMER_CFG_32_BIT_PER);
	TimerLoadSet	(TIMER2_BASE,TIMER_A,ONE_KHZ);

	TimerIntRegister(TIMER2_BASE,TIMER_A, Task1ms);
	TimerIntClear	(TIMER2_BASE,TIMER_TIMA_TIMEOUT);
	TimerIntEnable	(TIMER2_BASE,TIMER_TIMA_TIMEOUT);

	TimerEnable		(TIMER2_BASE,TIMER_A);

So... why is this happening? Interestingly, the stack is only like this when in the context of the Task1ms... back in the main loop (or other interrupt handlers) the stack is not like this.

over 10 years ago

0 Sal Pezzino over 10 years ago

TI__Mastermind 32995 points

Hi William,

It looks like you are continuing to enter the same functions recursively Task1ms() and SysCtlDelay(). And this may be causing a problem with your stack. It may be overflowing or corrupted.

Are you clearing the PIE by writing to PIEACK at the beginning of your ISR? It looks like you are entering the ISR again from inside of the ISR.

Please see the Peripheral Interrupts section of the Technical Reference Manual for F28M35x.

sal

0 Wil P. over 10 years ago in reply to Sal Pezzino

Expert 1660 points

Hi Sal,

Thanks for your response.

The very first line of code in the interrupt handler is:

void Task1ms(void)
{
	TimerIntClear(TIMER2_BASE,TIMER_TIMA_TIMEOUT);

...

So, I believe that the interrupt is being handled properly.

If I put a breakpoint in the main loop, the stack trace is:

It really only looks like it is messed up when it is in the context of the 1ms task. Any suggestions for a test?

0 Sal Pezzino over 10 years ago in reply to Wil P.

TI__Mastermind 32995 points

Hi William,

It seems like you are getting nested interrupts. I am not very familiar with interrupts on the M3 and am asking another engineer for some help.

Do you have a long delay in the Task1ms ISR that would be causing another TimerA interrupt?

Is your program failing?

sal

0 Wil P. over 10 years ago in reply to Sal Pezzino

Expert 1660 points

There are no explicit delays in our code; I believe that any delay seen is implicit to some TI Function.

I keep paring down the contents of the 1ms Task to ensure that interrupts are not nesting but nothing is helping. Note again, that the stack trace shown in the first post was from a single break point at the top of the 1ms interrupt from the start of the program; It should be the first time that the interrupt was ever entered.

The program is not failing or restarting... yet. But this issue is consuming about 1/4 or so of the stack (as can be seen in the first post). This is code for production that is close to release, I can not have such a large, unknown matzo ball out there.

General Question: Is there anything about nested interrupts in the M3 that is different than other processors? Like if I use states/flags to protect long functions from multiple calls - is there any issue with this?

0 Wil P. over 10 years ago in reply to Wil P.

Expert 1660 points

Well, this is weird...

I put a breakpoint at the top of the Task:

And after single code step...

0 Sal Pezzino over 10 years ago in reply to Wil P.

TI__Mastermind 32995 points

I wonder if there is something up with CCS.

Did g_OneMSCounter increase the number of times equal to the increase int the depth of the calls in your stack window? With that single step, did g_OneMSCounter increase?

sal

0 Santosh Athuru over 10 years ago in reply to Sal Pezzino

TI__Mastermind 19810 points

is your task calling the SysCtlDelay() function? is the delay larger than 1ms? Also can you check if SysCtlDelay() is being executed from RAM or flash, I thought this was part of RAMFUNCs.

Best Regards

Santosh

0 Wil P. over 10 years ago in reply to Santosh Athuru

Expert 1660 points

Santosh! Hello there.

No task of mine calls SysCtlDelay() (at least not directly). SysCtlDelay() seems to appear after a reset and appears a few times in the "SysCtlClockConfigSet" function.

If you read above, you will see that I reduced the 1ms task to a few instructions, and still saw this issue.

Also, I moved SysCtlDelay and Task1ms to RAM (Unfortunately not much improvement)

20006979   SysCtlDelay
20006981   Task1ms

Note, I do not think that SysCtlDelay is normally set to run from ram.

0 Wil P. over 10 years ago in reply to Sal Pezzino

Expert 1660 points

Sal,

With at least 4 Task1ms() frames on the stack, I only see 1 for the g_OneMSCounter .

0 Sal Pezzino over 10 years ago in reply to Wil P.

TI__Mastermind 32995 points

Is the stack corrupted with 0xA5? Can you try filling the .stack in the linker command file and see if the stack is being corrupted by these apparent function calls?

Because g_OneMSCounter is only incrementing by 1, either this is a problem with CCS not displaying the correct calls on the stack or the ISR is being interrupted by the same ISR.

Do you see the same behavior if you put the breakpoint on "g_OneMSCounter++;" and then single step?
sal

0 Wil P. over 10 years ago in reply to Sal Pezzino

Expert 1660 points

I am using a Linker FILL to place A5 in the entire stack currently.

"ISR being interrupted by the ISR" - can you explain that? Wouldn't the IntClear fix that?

Anything past that first step displays the inflated stack. After that one balloon step, the stack behaves as I understand that it should.

0 Sal Pezzino over 10 years ago in reply to Wil P.

TI__Mastermind 32995 points

Yes, IntClear should prevent that. I was asking if by setting a breakpoint on IntClear was causing this problem. If you set the breakpoint on the next statement or a couple of statements below the IntClear, does this problem persist?

sal

0 Wil P. over 10 years ago in reply to Sal Pezzino

Expert 1660 points

Yes, anywhere in the interrupt after the first line. In fact, there is a 500ms Task where this happens too, does not seem limited to just that task.

I am using ARM v5.1.10 compiler and CCS Version: 6.1.0.00104

BTW, what happened to my last post?

0 Sal Pezzino over 10 years ago in reply to Wil P.

TI__Mastermind 32995 points

I am not sure where the other post went...

What/how many interrupts does your system have? What are the priorities of these interrupts?

sal

0 Wil P. over 10 years ago in reply to Sal Pezzino

Expert 1660 points

All peripherals on the M3 are interrupt-driven.

However, at this point, only SCI and the timer are enabled.

No, priorities are set - should I be doing this?

0 Wil P. over 10 years ago in reply to Wil P.

Expert 1660 points

Please answer a question for me here:

Should an interrupt be able to interrupt itself? Is this a configuration setting somewhere?

If I put a 40ms task inside the 1ms task, it does not interrupt itself.

Consider the psuedo-code

void Task1ms()
{
    clearInt();
    counter++;
    if (taskrunning == 0)
    {
        taskrunning = 1;
        GPIOpin2 = 1
        40msTask();
        GPIOpin2 = 0
    }
    
<breakpoint>
}

In this case, I see the counter only increase once and measure the GPIO toggle at about 40ms... I would expect the counter to increase once per interrupt.

NOTE: I confirmed the 1ms timing using external tools many many times before (without the long task). It is spot on.

0 Wil P. over 10 years ago in reply to Wil P.

Expert 1660 points

Ok, figured out the problem... The stack was moved from the default 0x20004900 to somewhere else. Once I moved it back the problem went away! Apparently, the stack MUST be at that default address.

I will create a new thread for my interrupt question.

C2000™︎ microcontrollers

C2000 microcontrollers forum

Weird Stack problem - Concerto M3