• State TI Thinks Resolved
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 140 views
  • Users 0 members are here
Support feedback
Options
Options
Related

F29H85X-SOM-EVM: F29x SSU configuration for FreeRTOS Tasks - separate Sandboxes for Tasks

Sophia Rüth
Prodigy 30 points

Part Number: F29H85X-SOM-EVM

Hello,

I am working with the F29H85x-SOM-EVM to test SSU functionality in combination with FreeRTOS. 

I have tested different scenarios for SSU configuration, like having a FreeRTOS task in a different LINK but in the same STACK as the FreeRTOS context (similar to freertos_ssu_demo), or calling a function from a FreeRTOS task where the function is in a different STACK.


Now, I am trying to have the task in a different STACK

With this, I always run into a PR instruction security violation when switching to the task context (at the end of portRESTORE_FIRST_CONTEXT). I am guessing the SSU blocks the crossing of the STACK boundary when the scheduler tries to switch to the task context?
Is it possible to make the FreeRTOS use protected calls when entering tasks? How would I be able to make this scenario work?

Thanks!
Sophia

  • 0
    TI__Mastermind 27050 points

    Hi Sophia,

    Thank you for your question. Apologies on the delay. 

    May I know your intent behind utilizing the different SSU STACKs across the application? In the context of FreeRTOS, each TASK has its own STACK and this would be an individual APR assigned to a LINK (assuming you configure it in such manner), and thus at a LINK level you can seperate write permissions for the STACK (by only giving the respective LINK access to that APR that is encompassing the STACK for the TASKS that map to that LINK). 

    Sophia Rüth said:
    Is it possible to make the FreeRTOS use protected calls when entering tasks? How would I be able to make this scenario work?

    I have assigned this thread to our FreeRTOS expert for further commentary on this matter.

    Best Regards,

    Marlyn

  • 0 in reply to Marlyn Rosales Castaneda20
    TI__Expert 3655 points

    Hi Sophia,

    Having the scope of FreeRTOS span multiple SSU STACKs would not work out. This would require switching to a new STACK within an interrupt context AND ensuring that entry conditions are correct in the new task, which is not really supported. Even if we could hypothetically setup up a working system with tasks in multiple STACKs, another major blocker here is that the tick interrupt would not go through until the code execution returns to the STACK in which it resides. 

    Our recommendation remains placing all FreeRTOS components in a single STACK, with one LINK per task (or) group of tasks with identical permission levels.

    Regards,

    Arnav

  • 0 in reply to Arnav Menon R
    Prodigy 30 points

    Hi Marlyn and Arnav,

    Thanks for the explanation. To avoid confusion with the FreeRTOS task stack memory, I would like to use the term sandbox when referring to an SSU STACK from here on.

    My motivation for placing tasks in separate sandboxes was to strengthen isolation between application code and the FreeRTOS infrastructure. If all tasks and the RTOS execute within the same sandbox, the sandbox stack APR appears to be accessible to all code running in that sandbox. Even though each FreeRTOS task has its own stack memory region, I was concerned that a non-trusted task might still be able to corrupt the RTOS execution context or sandbox stack.

    However, from my testing it appears that the sandbox stack is not actively used anymore once the scheduler has started. Is that understanding correct? If so, the concern that originally led me to place tasks in separate sandboxes may not actually apply.

    However, I would like to better understand the implications of the following statement:

    Arnav Menon R said:
    the tick interrupt would not go through until the code execution returns to the STACK in which it resides.

    Could you clarify how interrupts interact with SSU SANDBOX boundaries in general?

    For example, suppose FreeRTOS remains entirely within SANDBOX 2 as recommended, but some application code executes in SANDBOX 3:

    • If code is currently executing in SANDBOX 3, can an interrupt whose handler resides in SANDBOX  2 still be taken?
    • Does the interrupt entry mechanism automatically perform a SANDBOX transition, or are interrupts restricted to the currently active SANDBOX ?
    • Would a timer ISR (such as the FreeRTOS tick interrupt) be blocked while executing in another SANDBOX , or is this limitation specific to the FreeRTOS task-switching mechanism?

    The reason I am asking is that I would like to understand whether the restriction is specific to FreeRTOS scheduling, or whether any code executing in a different SSU SANDBOX would also prevent interrupts located in another SANDBOX from running.

    Thanks for your help.

    Kind regards,

    Sophia
  • 0 in reply to Sophia Rüth
    TI__Expert 3655 points

    Hi Sophia,

    You are right, up until the scheduler starts, the initial Sandbox's stack will be utilized. Once the scheduler has started and the first task is swapped in, the current stack will be the one belonging to the currently running task. Even if an interrupt comes in, it will continue to use that task's stack. All this is true regardless of whether SSU is active or not.

    In C29x, the application must choose a Sandbox that INT (low priority interrupts) will execute from. Interrupt_initModule API sets this to SANDBOX2 by default. Note: This restriction does not apply to RTINT and NMI!!

    To answer your questions (assuming the interrupt is an INT, which should also be the case for tick interrupt)

    1) The interrupt will stay pending until the execution returns to code in INTSP Sandbox

    2) There is no automatic transition.

    3) Correct, while we are in a Sandbox other than INTSP, any pending interrupt would stay blocked. This is a characteristic of the C29x CPU, and not something specific to FreeRTOS.

    More info about the INTSP register and its behaviour can be found in the TRM and the C29 CPU Guide. Let us know if you have any more questions.

    Regards,

    Arnav