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.

TMS320F28069: ISR stack usage in combination with an RTOS

Part Number: TMS320F28069
Other Parts Discussed in Thread: SYSBIOS

Hello,

ive come across a problem with my software which causes it to randomly fail due to stack overflow issue. At first im using an RTOS with roughly 10 Tasks. When an interrupt occurs it is mostly inside the stack of one of them. In order to do this all task stacks have to be larger to fit the random occurance of the various interrupts. Not only this wastes a lot of memory but im slowly reaching the memory limits of the part.

My question is now how do i redirect the stack pointer to a dedicated stack section only for interrupts. Also how does a rewrite of the stack pointer interact with interrupt nesting. In my understanding each entry of an isr has to first check if the stackpointer is within its dedicated section if not perform a rewrite otherwise just leave it as it is. The last isr that did the stack point relocation has to revert it to the original.
What would be the right way to implement this in software and in the linker and are there maybe other ways to achieve something similar. The number of important interrupts is rather small (3 or so) is it better to use an other technique to statically have a stack for each interrupt instead of a shared for all interrupts.

Thanks in Advance

Tobias

  • Are you writing your own RTOS or using one of our existing implementations (like FreeRTOS or SYSBIOS)? If you are developing your own, you could take a look at those existing implementations to get an idea of how to handle this. I'm not aware of any implementation that has separate stacks for each interrupt though.

    Whitney

  • It is an older version of FreeRTOS. Some parts are slightly tweaked but nothing important regarding my concern.
    Im not looking into seperating each isr into its own stack. I want to to have one stack for some selected ISRs. My idea was to reuse the regular C stack which has to be maintained until FreeRTOS takes over. This would involve the retrieval of the stack pointer address used to the point it is no longer used and than redirecting some ISRs to that memory segment.

    Tobias

  • Hi Tobias,

    I am checking with compiler team on changing the stacks inside ISRs.

    Meanwhile, another solution I can think of is, to offload the ISR content to a task. ISR can just call a SemPost/TaskNotify function to unblock the task. You can have a dedicated stack for this task and assign priority as needed. Does this solution work in your case?

    Regards.

    Veena 

  • Hi Veena,

    Thanks for the effort.
    First of all this is an interesting solution you propose but im quite unsure if i can meet the latency requirement with delegating it to an extra task. For information im doing Foc based motor control and im tight on computational power and memory as well.
    My prefered way is still to relocate the stack to some other location for one or two ISRs. Even if it would not be the same stack it would safe a lot of memory.
    Kind regards.

    Tobias

  • I am checking with compiler team on changing the stacks inside ISRs.

    Unfortunately, the compiler has no features which support reading or writing the SP (stack pointer).  All things considered, such operations are best implemented in hand-coded assembly functions.  I'm not aware of any examples of such functions.

    Thanks and regards,

    -George

  • The SYS/BIOS "Hwi dispatcher" has some assembly code for updating the stack pointer when entering and leaving an interrupt. If I recall correctly, it uses the regular system stack (.stack in your cmd file) for ISRs like you described. That's the closet example I can think of.

    If you have SYS/BIOS installed, the code to look at is in bios_6_83_00_18\packages\ti\sysbios\family\c28\.

    Whitney

  • Hello Whitney,

    Thats a really good point. I will look into it and then reply what i found. At the moment im trying to figure out how to get the actual SP before the RTOS takes over and evaluate if it is needed to wrap most of the init function prior to that into a seperate function to free up stack from lots of calls.