RTOS/TM4C1294NCPDT: ISR Handler issue - Stack out of boundary

Have you used ROV to look at the stack peaks for both the Tasks and Hwi stacks? Here are some debugging tips for finding stack overflows: training.ti.com/debugging-common-application-issues-ti-rtos

Todd

Hi Todd,

I have narrow down the issue by using break point and watching variables. the problem with Semphore_post in HWI context.

when I used two tasks i.e. one for HWI and other one is normal task, I am posting Semaphore in HWI handler whenever GPIO is high and other task is running in while loop and waiting for Semaphore pend which is posted in HWI handler. I don't have any issue in these case by posting semaphore in HWI context.

when I add 10 more task along with this, then the semaphore post returning error saying that stack out of boundary. i have increased the system stack upto 8Kbytes but still it didn't worked.

the main difference here is inside the semaphore_post() function call,
file path: C:\ti\tirtos_tivac_2_16_01_14\products\bios_6_45_02_31\packages\ti\sysbios\knl\Semaphore.c

/* lock task scheduler */
tskKey = Task_disable();

tskKey = 1(TRUE) working condition with Two task is running.
tskKey = 0 (FALSE)not working condition when added more task.

because the of this value, Task_restore(tskKey); function fails and returning the Stack error.

I tried replacing the Semaphore_post() with Swi_post(), then function is switching to SWI task whenever interrupt is occurred and all other task is also running great. here i have used default system stack i.e. 512 bytes.

so strongly believe that this problem is not because of insufficient stack memory.

can you please suggest me the solution for this problem.

Regards
Bala

Here is my code for both the scenario.

/* ISR handler */
void DigitalInputISRHandler()
{

(* (volatile uint32_t *)clearFlagaddr) = bit_shift;
GPIO_toggle(Board_LED0);

/*Semaphore post to process the digital input status */
Semaphore_post(DigitalInputProcessing);
}


void DigitalInputProcessingFunc()
{
while(1)
{
Semaphore_pend(DigitalInputProcessing, BIOS_WAIT_FOREVER);
GPIO_toggle(Board_LED1);
}
}

How did you create the ISR? Via Hwi_create (or Hwi_construct)? Can you post the code where you create the ISR?

Hi Todd,

i am creating HWI using XDC GUI tool. after creating in GUI, i am getting the following code in project.cfg file.

/* ================ Application Specific Instances ================ */
var halHwi0Params = new halHwi.Params();
halHwi0Params.instance.name = "DigitalInputISRHandler";
Program.global.DigitalInputISRHandler = halHwi.create(null, "&DigitalInputISRHandlerFunc", halHwi0Params);

Regards
Bala

I'm not really sure what is happening. After reading through the thread again, I noticed you have not explicitly said you increased the Task stack size. Can you confirm how much task stack space is being used? You can see this in the ROV->Task->Details view.

Todd

Hi Todd,
I have increased the system stack up to 8096 bytes and checked since HWI ISR handler uses system stack. by default it was 512 bytes. remaining all other tasks are using default stack size 512 bytes.

Regards
Bala

Are you disabling Tasks yourself anywhere?

1. Can you please attach a picture of ROV->Tasks->Detailed and make sure to include the entire view.
2. Can you please attach a picture of ROV->Tasks->Module and make sure to include the entire view.
3. Can you please attach a picture of the stack error you are seeing?

Todd

Hi Todd,

Please find the below picture of requested items.

Stack Error

Task detailed View

Task module view

Regards

Bala

Hi Bala,

It looks like the first problem is that an duplicate ISR is trying to be created.

Look in ROV->Hwi->Basic to see what interrupt 67 is and why you are trying to create it again.

Todd

Hi Todd,

I am not using this HWI for my project and its getting assigned by default. I am not getting this warning if no HWI is defined in my project for GPIO interrupt. If I defined any GPIO port as an interrupt source for HWI, then i will be getting the same warning. so this time i have tried change my Interrupt source PORT H and vector number is 48 instead of 67. then also i am getting the same warning. i have attached the snapshot for your reference.

Regards

Bala

Hi Bala,

All the images appear to be the same. I expect it's an e2e forum issue. I've found you cannot post the same file name even if the images are different at the time of posting. Can you put in the ROV->Hwi->Detailed snapshot? Or if you have CCS 7.2 or higher, open Tools->Runtime Object View->Hwi->Detailed and save the output to a file and attach that file.

Todd

Hi Todd,

Please find the below snapshot of my ROV->HWI detailed view. This snapshot is after stack error. i.e. after GPIO interrupt.

Bala,

That's the ROV->Task->Detailed view. Can you attach the ROV->Hwi->Detailed?

Todd

Sorry Todd, wrongly uploaded. this time is correct one.

Regards

Bala

This is not good. It looks like the vector table is messed up. I don't you have Sem_i2c_Handle is a Hwi function. Any idea where these came from? Can you look at this view when you are in main? If it's good then, maybe place some breakpoints in your app to figure out when this corruption occurs.

Todd

Hi Todd,
I am using this i2c_handle function in one of the task but i have not specifically assigned as Hwi function. it coming automatically when i call i2c related function.

another observation is here for stack error.

There is no stack error when i am using less than 4 events/semaphore in my application. if i use more than that i will be getting stack the stack error which i mentioned earlier of this thread.

Is there any limitation of using number of semaphore/event/mailbox?
If we need to use more than that what parameters needs to be tuned in TI RTOS?

Regards
Bala

There is no limit. What does the ROV->Hwi->Detailed look like when you halt at the beginning of main()? What about before you call BIOS_start? What about before and after your calls to any driver open calls? I expect you have a bad pointer somewhere and you are corrupting memory.

Todd,

Sorry to barge in here, but I wanted to ask how you could tell that the vector table was corrupted? Is it because of the intNum / priority / group / subPriority being all zeroes?

I am having a similar situation (right from the start of Main) where one of the interrupts - whose function name is shown only as '_ASM_' remains all zeroes, and the address for it contains only zeroes.

Hi Stan,

The big clue was that Sem_i2c_Handle was a Hwi function for multiple instances. This just looks too fishy. The all zeros was not a good sign either. Note: certain versions of ROV (actually XDCtools) do not handle constructed objects well before they are constructed. For example, if you have a Semaphore_Struct or Hwi_Struct global variable, ROV might not display it properly before it is constructed. Depending on the location of the struct, it might not even show up. Created objects do not have this problem. Here is a discussion of created vs constructed objects: processors.wiki.ti.com/.../TI-RTOS_Object_Creation_Comparison

Todd

Hi Todd,

i didnt find the exact root cause of this problem. but i deleted the HWI handler and created once again in GUI tool and Now its working fine. i am just wondering how the things running now?

Regards
Bala