• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 580 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

TMS320F2812: Stack pointer and size questions and issues

TMS320F2812: TI-RTOS Number of Stack Usage Problem

Ismail Halit KARAKAS
Prodigy 90 points
Part Number: TMS320F2812


I do use either ROV Classic during debugging or RTOS APIs  in my code to measure how much stack usage has been made in the firmware.

I have 12 task and almost all of them shown as  #of StackUsed = Total Stack Size -1. E.g. If I allocated 256 byte, it show 255. Even if I increase the stack size to e.g. 512 to see what's gonna change, then  ROV shows 511 as # of StackUsed.

It was not like that before.

What kind of problems my codes could have ? 

I haven't encountered any stackoverflow issue so far.

Even if I change the stack size of a task which is e.g. 512 to 384 ( I know that function used to work at that stack size before), It is working but still shows %99 usage.

  • 0
    TI__Guru 54195 points

    What versions of CCS and SYS/BIOS are you using?

    Have you checked out any of the stacks in the Memory Browser to see what their actual usage looks like? ROV should give you the stack base address you can use to look them up and BIOS fills the stacks with a distinctive pattern to make it easy to see how much has been used.

    If you call Task_stat() for the tasks in question, does it return anything unexpected?

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 90 points

    Hi 
    Thanks for the message,
    I am using CCS V12.

    It looks stacks are filled out somehow. 
    This is really weird. Increasing or decreasing stack size has no impact.

    Or is there a possibility like the function filling stack memories with 00BE00BE is somehow not working ?



  • 0 in reply to Ismail Halit KARAKAS
    Prodigy 90 points

    It may seem weird but I tampered with the stack size of a task by dropping it to 128, which is a value that triggers the stack overflow function of the kernel, so it happened. Then I reverted that stack size to 256 which is its value. Then this issue was fixed, and values came back to normal. I don't know what kind of thing has broken that usage monitoring.
    So we don't know if it is going to give the same failure at any time of a run either.

  • 0 in reply to Ismail Halit KARAKAS
    TI__Guru 54195 points

    That is pretty weird. As far as I can tell, BIOS fills the stacks when the Task is created, so if you're creating the tasks statically (in your cfg file) they should be 0x00BE from the start of main(), and if you're creating them dynamically, they should be filled after Task_create(). If it happens again, it'd be interesting to confirm that they are 0x00BE at least to start and then use place some breakpoints and try to narrow down what is overwriting them

    ROV appears to be using the 0x00BE markers to determine stack peak. It's kind of strange that in your screen captures, the last word of all the stacks is still 0x00BE. If some overflowing buffer was overwriting your stack memory, I'm not sure why would that final word stay intact.

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 90 points

    I've checked the memory areas when my breakpoint was in either the start of my main or "_c_int00" function which is in start-up section.

    The memory was "abnormal" in each case like I shared above.

    to let you know where _c_int00 is,  please see below.

  • 0 in reply to Ismail Halit KARAKAS
    TI__Guru 54195 points

    The start of c_int00 is too early to see it. I think stacks are initialized as part of the Startup_firstFxns calls (see the BIOS boot flow here). Below shows what my Idle Task stack looks like at the start of main(). There are a few words used at the start, but it's still mostly 0x00BE.

    Again, the above only applies to .cfg files tasks. If you're calling Task_create(), that's the place to check.

    Whitney