• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 97 subscribers
  • Views 970 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.

SWI Resource Utilization

Jordon
Intellectual 635 points

Hello,

I am analyzing my heap and stack usage and I am wondering if anyone can tell me how much heap, stack and system stack a SWI utilizes. My SWIs are currently allocated on the heap.

Thanks. 

  • 0
    TI__Expert 4095 points

    SWIs run on the system stack, and don't have their own individual stacks (like TSKs do). The system stack usage will of course depend on what you do in your Swi.

    When you create a SWI, it does have a state structure that is allocated from your heap. I think it has a type such as SWI_Object that you could call sizeof() on to determine its size.

    Chris

  • 0 in reply to Chris McCormick
    Intellectual 635 points

    Hi Chris,

    Thanks for the reply. I found using MEM_stats that each SWI_create() takes 0x1C of heap. However when I tried to reduce the normal stack (not the system stack), I got a warning from the TCF editor and also the following error when I built the code. This seems to suggest that SWIs use the normal stack, not the system stack? 

    "OMAP7200cfg.s55", WARNING! at line 51: [ ***** USER WARNING ***** - ]

             Application stack size is too small; decrease the number of SWI

               priorities or increase the stack in MEM.

    .wmsg "Application stack size is too small; decrease the number of SWI priorities or increase the stack in MEM."

    No Assembly Errors, 1 Assembly Warning

    Again I was decreasing the stack in MEM not the system stack. 

    Thanks for the help.

    Jordon

  • 0 in reply to Jordon
    TI__Expert 4095 points

    There's no normal stack vs. system stack--there's just the system stack. You're getting that error because the system stack is not large enough for the SWIs that you've configured. I asked someone about this error and here's the response:

    "In BIOS5, we calculate the minimum stack size required to handle the number of SWI priorities used by the app.  If the guy has 2 SWIs (one at pri 3 and one at pri 10), we assume nesting depth of 10 and require stack to be big enough to handle 10 nested SWIs.

    He needs to make stack bigger, or use less SWI priorities.  And use lower, contiguous numbers for SWIs instead of any gaps."

    Thanks,

    Chris

  • 0 in reply to Chris McCormick
    Intellectual 635 points

    Hi Chris,

    Thanks for the information. I still have a few questions:

    1) How can the stack depth be calculated at compile time if your application uses dynamic SWI priorities? For example, we set our SWI priorities based on a dynamic lookup table of SWIs. We use the full range of SWI priorities.So in our case the system stack depth would need to be the max depth if I understand correctly. So how would I calculate the "max" system stack assuming it cannot be calculated at compile time in our case? Would it just be the 15 * sizeof heap allocation at SWI_create()?

    2) System stack vs. normal stack: I ask this because in the system BIOS config tool for the MEM manager General Tab, there is a field for "system stack size (MAUs)" and the "Stack Size (MAUs)" so I am still missing the difference. So based on the error I am to believe that I should be adjusting the "Stack Size (MAUs)" based on my SWI usage but we are talking about SWIs using the system stack. It seems like there is a disconnect.

    Thank you for your assistance.

    Jordon

  • 0 in reply to Jordon
    TI__Mastermind 20805 points

    Jordon said:

    1) How can the stack depth be calculated at compile time if your application uses dynamic SWI priorities? For example, we set our SWI priorities based on a dynamic lookup table of SWIs. We use the full range of SWI priorities.So in our case the system stack depth would need to be the max depth if I understand correctly. So how would I calculate the "max" system stack assuming it cannot be calculated at compile time in our case? Would it just be the 15 * sizeof heap allocation at SWI_create()?

    If you have 15 distinct SWI priorities, it is possible that if timing is just right (wrong) the SWI of priority 15 could preempt 14, which could preempt 13, which could preempt 12, etc.  Each preemption requires register context to be saved so the stack has to be pretty big.   We have SWI priorities to allow fast response for time-critical events.   The highest priority SWI should run ASAP.   But, in most systems, there are only 2 or 3 events that are really time critical and you can often group the other SWIs at the same priority and avoid 2 things: (1) the need for a big stack, and (2) oeverhead required for preemption.  If you have multiple SWIs at same priority, they will run in FIFO order (within that priority group) with less overhead than if you have SWIs at different priorities.   If your system does not require 15 unique priorities, I'd try to collapse this down to a smaller set and use priority 1-max where max is much less than 15.  

    The estimated stack size can only be done at configuration time.  If you are creating SWIs at runtime, then we cannot check the stack size.   But, if you set the priorities and SWIs at configuration time, we are able to check to see that the stack is within reasonable size.   If you have a SWI of priority 15, we assume that you have SWIs of 14, 13, etc. at runtime and need to make sure that the stack is big enough.  We know how much BIOS uses, and not  your app of course.  But if BIOS needs X words for each priority nesting, then we can multiply X*N and compute minimum stack size.

    Jordon said:

    2) System stack vs. normal stack: I ask this because in the system BIOS config tool for the MEM manager General Tab, there is a field for "system stack size (MAUs)" and the "Stack Size (MAUs)" so I am still missing the difference. So based on the error I am to believe that I should be adjusting the "Stack Size (MAUs)" based on my SWI usage but we are talking about SWIs using the system stack. It seems like there is a disconnect.

    If you are using the 55x, then things get confusing.  The 55x hardware has 2 stacks which I think they call the stack and the system stack.    BIOS logically has a stack per task, but in the 55x case, we need to maintain 2 stack pointers to support the dual-stack hardware architecture.    BIOS also has a separate stack for use by HWI and SWI processing.   We often call this the system stack, but we should probably call this the ISR stack.   The ISR stack also has 2 components because of the dual-stack on 55x.  The hardware uses much more 'stack' than 'system stack'.  The system stack is used to hold high-half of return addresses and some status register context at ISR time.  But, most registers and C context is saved on the 'stack'.   I think rule of thumb is to make stack 4x bigger than system stack.


    -Karl-

     

  • 0 in reply to Karl Wechsler
    Intellectual 635 points

    Karl thanks for the detailed response that focused in on my confusion. That really helped me get my head on straight (or straighter). It gives me some things to think about to reduce our stack(s) ;) requirements.