• Locked Locked
  • Replies 3 replies
  • Subscribers 119 subscribers
  • Views 3038 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex-M3 Thread mode stack

Marcus Harnisch
Note: This was originally posted on 25th August 2010 at http://forums.arm.com

Gentlemen

I am wondering if, while processing an arbitrarily nested ISR, there is a reliable way to determine which stack thread mode is using (process or main). The CONTROL register seems not appropriate since the SPSEL bit is reserved in Handler mode. The only other place I can think of is the (stacked) link register of the ISR preempting thread mode. But how do I get to it? We don't know the sizes of stack frames in between this and the current ISR. I must have missed something...

Thanks
Marcus
Parents
  • Note: This was originally posted on 25th August 2010 at http://forums.arm.com

    ...the stack pointer selection can be changed by the value of EXC_RETURN when you carry out an exception return to thread.

    That is exactly what I am doing. Similar to the untrusted ISR example in your book. Ideally, I would want the untrusted ISR use the same stack that "normal" thread mode uses. For that I'd need the EXC_RETURN of the ISR that preempted Thread mode in the first place. Since the goal is a short paper, I am clearly over-engineering this to show some features.
    In my current implementation, it must be ensured that the user ISR is the first ISR, i.e. has lowest prio of all, so that I can access its EXC_RETURN directly. In practice, this limitation is not that big of a deal since giving a non-trusted ISR a higher priority than other ISR creates the potential of many other issues.

    Thanks
    Marcus
Reply
  • Note: This was originally posted on 25th August 2010 at http://forums.arm.com

    ...the stack pointer selection can be changed by the value of EXC_RETURN when you carry out an exception return to thread.

    That is exactly what I am doing. Similar to the untrusted ISR example in your book. Ideally, I would want the untrusted ISR use the same stack that "normal" thread mode uses. For that I'd need the EXC_RETURN of the ISR that preempted Thread mode in the first place. Since the goal is a short paper, I am clearly over-engineering this to show some features.
    In my current implementation, it must be ensured that the user ISR is the first ISR, i.e. has lowest prio of all, so that I can access its EXC_RETURN directly. In practice, this limitation is not that big of a deal since giving a non-trusted ISR a higher priority than other ISR creates the potential of many other issues.

    Thanks
    Marcus
Children
No data