Can I check for F2812 stack overflow from task context?

Lyn Harris

I'm new to a program using the F2812 (DSP/BIOS and CCSv2, ugh). Instead of calling TSK_checkstacks() via the task Switch function, the code calls it from the Idle task. It turns out that even when I force a stack overflow, I don't see a SYS_abort called. In other words, the stack checking isn't working.

I've verified that the task I cause to overflow in one of the 11 being checked (see code below), and I've also verified that the entries in the StackCheck.tasks array are usable by the other TSK_<functions> such as TSK_getname(), TSK_stat(), and TSK_getpri(). My method for forcing a stack overflow was to reduce the size of the task stack in the *.cdb file until it could still start up correctly, but then would overflow after a few minutes of operation.

Should I be able to get it to work from the Idle task? If possible, this would be nice to do since this is production code and I want to minimize changes. If this is not a workable solution, I'd like to know so I can move on. I have no idea why the original designers made the choice to run from the Idle task instead of via the task Switch function, and they are long gone.

#define NUM_STACK_CHECKS 11

static void BackgroundStackOveflowCheck(void)
{
USHORT i;

/*
* Check the stacks for overflow.
*/
for (i = 0; i < NUM_STACK_CHECKS; i++)
{
/*
* update the taskID that will be tested next,
* we use this taskID for reporting if test fails.
*/
currentTaskID = i;

StackCheck.current_task = StackCheck.tasks[i];

/*
* Will call gAbort if the oveflow check fails.
*/
TSK_checkstacks(StackCheck.tasks[i], StackCheck.tasks[i]);
}

/*
* Update the statistics.
*/
StackCheck.count++;
}

thanks,

Lyn

over 13 years ago

0 Steven Connell over 13 years ago

TI__Mastermind 45025 points

Hi Lyn,

Which version of DSP/BIOS are you using?

How are the tasks being created? Are they created at run time via TSK_create() calls? Or statically within the BIOS configuration file (*.tcf)?

If they are being dynamically created, then you must make sure that the initstackflag attribute in the TSK_Attrs structure is being set.

When you look at the stacks in memory, do you see them initialized with TSK_STACKSTAMP? ( == 0xBEEF ...)

What happens if you call TSK_checkstacks() from within your task that you are purposely overflowing?

Steve

0 Lyn Harris over 13 years ago in reply to Steven Connell

Prodigy 110 points

Hi Steve,

Many thanks for your response. This is old stuff, we have DSP/BIOS 4.90.280 06-24-03 (barracuda-m11). I'm trying to get us to upgrade to CCSv5 with newer SYS/BIOS, but progress takes time.

The tasks are created statically within the BIOS configuration file.

I tried looking at the unused stack in memory, but this has been problematic so far. Apparently we've been unable to emulate our system with the XDS510 boxes we have; am trying to get XDS560's purchased since they are reportedly fast enough to emulate. I've tried to copy data out of memory and send across CAN while the system is running. I can get 1 16-bit chunk, but if I try to grab a second the system crashes hard. That one 16-bit chunk I got was all zeros. I haven't tried yet, but the XDS510 is supposed to work ok with 1 hw breakpoint as long as there is no restarting; do you recommend that I try looking at stack after hitting the hw breakpoint?

The version of the manual that came with our system omits the value of TSK_STACKSTAMP (e.g., the #define is empty, although I assumed it was accidently empty). I found a newer version of the manual online that says it should be 0xBEBEBEBE (I think...working from memory). So I'm not even 100% confident what the value is I'm looking for. Can you confirm what the value would be for my DSP/BIOS?

I have not tried calling TSK_checkstacks() from the overflowing task. I can try this.

-Lyn

0 Steven Connell over 13 years ago in reply to Lyn Harris

TI__Mastermind 45025 points

Lyn,

Ok, wow, yes you're definitely on some old stuff here!

Lyn Harris said:
do you recommend that I try looking at stack after hitting the hw breakpoint?

Yes. Any insight you can get into the system is going to help you. If you can look at the stacks in the memory browser once the breakpoint hits, you should hopefully be able to see if they're overflowing.

Lyn Harris said:
The version of the manual that came with our system omits the value of TSK_STACKSTAMP (e.g., the #define is empty, although I assumed it was accidently empty). I found a newer version of the manual online that says it should be 0xBEBEBEBE (I think...working from memory). So I'm not even 100% confident what the value is I'm looking for. Can you confirm what the value would be for my DSP/BIOS?

I'm having a hard time finding the code for the version you're on, but I'm fairly certain that it should be 0xBEEF. I believe it was changed to 0xBE... for SYS/BIOS.

In any case, it will be an obvious pattern that's easy to spot when looking at the memory. See screen shot of what it looks like in SYS/BIOS. I'd expect similar for yours but with a "0xBEEF" pattern ...

Steve

0 Lyn Harris over 13 years ago in reply to Steven Connell

Prodigy 110 points

Steve,

I was able to verify that the pattern in use for my DSP/BIOS is 0xBEEF. I can see it in the memory view window, like you suggested. There are also a few 0xFFFF DEAD in there that look manmade, but

I still need to try calling TSK_checkstacks() from the overrunning task...

thanks,

Lyn

0 Lyn Harris over 12 years ago in reply to Lyn Harris

Prodigy 110 points

Steve,

I called TSK_checkstacks() from the overrunning task and saw the SYS_abort Abort function get called when I wrote 0x0's into the stack's unused space (plus one 16-bit byte past the end of the stack). I then switched back to calling TSK_checkstacks() from tskIdle and verified that the Abort function was not called. So it looks like your suggestion to call from the delinquent task was just what I needed.

This is a big help. Thanks so much.

-Lyn

Processors

Processors forum

Can I check for F2812 stack overflow from task context?