SWI, HWI and Task existence in same application

Sandeep Manjunatha

Other Parts Discussed in Thread: SYSBIOS

Dear All,

My application needs multiple processes deployed as SWI, coprocessors having their ISR(executing in HWI context), and single low priority task which runs only a while(TRUE) loop after initializing the system. Can this mixed mode of modules be present in same application.?

Currently, my application is executing fine but stack usage of the low priority task is beyond 1kbytes. Before entering the while(TRUE) loop, the stack usage looks to be fine with minimal use. But after configuring the co-processor(FFTC and BCP), ISRs of the co-processors are using the low priority task's stack and I see a stack overflow.

As I understand, ISRs should use HWI stack which is _stack defined for system. Currently this is not the behavior what I am seeing.

Please let me know is there a way to force the ISRs to use the system stack, and not corrupt the task stack.

Also, if the single low priority task is changed to SWI, ISRs use the normal system stack and there seems to be no stack corruption. My requirement is to have a single low priority task executing with the SWIs and HWIs.

Thanks in advance.

Regards,

Sandeep M

over 12 years ago

0 Alan DeMars over 12 years ago

TI__Mastermind 30830 points

Sandeep,

Yes, your Hwi/Swi/Task use case is supported and very common.

As documented in section 3.5.3 of the SYS/BIOS User's Guide, while ISRs are indeed run on the HWI stack, in some cases of nested Hwis, a task stack may have to accommodate up to two Hwi contexts before the switch to the HWI stack is made.

In order to save memory in your application, you might consider simply adding your "while (TRUE)" function to the Idle task. That way you can increase the size of the Idle task stack as necessary and save the dedicated task stack altogether.

Alan

0 Sandeep Manjunatha over 12 years ago in reply to Alan DeMars

Prodigy 170 points

Hi Alan,

Thanks for your reply.

In my code there are no nested interrupts. This behavior is observed only in Core 0.

Other cores are running fine without stack overflow.

Maximum stack usage of low priority task in core 0 is 1028 bytes in this example. Low priority task stack size is 2048.

Earlier Low priority task stack size is declared to 1024. and max stack usage observed in ROV was 1024

Before executing the ISR Low priority task's stack usage is minimal (around 200 bytes) in Core 0.

I would like to know what could be the issue.

Please share the procedure to change the BIOS Idle task to add while(TRUE) and recompile the same.

I'm using C6670 EVM to execute the code and I do not see c66xx reference in the Table 3-7.

Regards,

Sandeep M

0 Alan DeMars over 12 years ago in reply to Sandeep Manjunatha

TI__Mastermind 30830 points

The C6670 will generally have the same stack usage as C674-core based devices.

If the ISR posts a Semaphore that readys a blocked task, then in addition to the ISR register context, a full Task register context will be pushed onto the pre-empted task's stack before switching to the new task. This is what is referred to in the User's guide as a "Task preemption context".

Also, the stack requirements of any Task Switch Hook functions you may have defined in your application will increase the task stack size requirements accordingly as the switch hook functions are run on the stack of the task being pre-empted.

To add your while loop to the Idle task, add the following to your config script:

var Idle = xdc.useModule('ti.sysbios.knl.Idle");

Idle.addFunc('&myIdleFunc'); /* adds myIdleFunc() to list of functions executed within the Idle task */

And in your C code:

Void myIdleFunc()

   while(TRUE) {
       ....
   }

Bear in mind that no other Idle functions are able to run while the processor sits in this loop. If this is not an issue for you, then you can reduce the number of tasks your application needs by one.

Alan

Processors

Processors forum

SWI, HWI and Task existence in same application