• State Not Answered
  • Locked Locked
  • Replies 33 replies
  • Subscribers 349 subscribers
  • Views 23993 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

Question : The Definitive Guide to the ARM Cortex-M3

Kenichi Kenichi
Note: This was originally posted on 11th December 2007 at http://forums.arm.com

Dear, all.

I am new in this forum.
Recently I studying Cortex-M3 core, so I bought book "The Definitive Guide to the ARM Cortex-M3" by Joseph Yiu.
This book is very good book and this explains most of unaswered questions by TRM or AALRM.

As I found some mistake in this book, I would like to feedback, but I could not find publisher's homepage. Then I found Josephe's name in this forum, I would like to ask here.

In page 42, there is fig 3.11 and 3.12 but this contents is same as fig 3.8 and 3.9.
Fig 3.8 and 3.9 should be some program list.

Can I get correct figure? Or where I should contact?
Please advise.

Kenichi
Parents
  • 0
    Note: This was originally posted on 23rd January 2010 at http://forums.arm.com

    Joseph,

    your book is really very useful !!

    There is something though that I can't understand or it is not quite precise. On p.135 you mention a "problem with context switching at IRQ".

    If an interrupt request takes place before the SYSTICK exception, the SYSTICK exception
    will preempt the IRQ handler. In this case, the OS should not carry out the context switching.


    this is correct The OS cannot change the context because the IRQ handler may have changed some of the top registers.

    Otherwise the IRQ handler process will be delayed, and for the Cortex-M3, a usage fault
    could be generated if the OS tries to switch to Thread mode when an interrupt is active.


    I have seen several RTOS implementations and it is also quite logical to use only the PSP for the taks. This means that there is no reason to change the LR when you do a context switch.

    And if you do not touch the LR (in SYSTICK) there will be no usage fault.

    And there is no way to delay the IRQs... The core will first try to tail chain all the IRQs that have higher priority than any stacked, and then the execution will return to the stacked ones if any. No user task can get control before all the IRQs are serviced out.

    So I think that there will be no IRQ delays or usage faults. The real problem is the preemption that can destroy the task contexts and the use of PendSvc is the correct solution. Another solution is to lower enough the SYSTICK priority.
    There is one more thing about the priorities. Sometimes you need to call protected system function (SVCs) not only from user tasks but also from ISRs. This means that the SVC exception must have a mid-priority and all kernel-aware IRQs must have lower priority otherwise they will end up with usage fault if they use the SVC instruction.  Then we will have
    - "fast" IRQs
    - SVC
    - kernel aware IRQs
    - SYSTICK
    - PendSV
    - user tasks

    Miro
Reply
  • 0
    Note: This was originally posted on 23rd January 2010 at http://forums.arm.com

    Joseph,

    your book is really very useful !!

    There is something though that I can't understand or it is not quite precise. On p.135 you mention a "problem with context switching at IRQ".

    If an interrupt request takes place before the SYSTICK exception, the SYSTICK exception
    will preempt the IRQ handler. In this case, the OS should not carry out the context switching.


    this is correct The OS cannot change the context because the IRQ handler may have changed some of the top registers.

    Otherwise the IRQ handler process will be delayed, and for the Cortex-M3, a usage fault
    could be generated if the OS tries to switch to Thread mode when an interrupt is active.


    I have seen several RTOS implementations and it is also quite logical to use only the PSP for the taks. This means that there is no reason to change the LR when you do a context switch.

    And if you do not touch the LR (in SYSTICK) there will be no usage fault.

    And there is no way to delay the IRQs... The core will first try to tail chain all the IRQs that have higher priority than any stacked, and then the execution will return to the stacked ones if any. No user task can get control before all the IRQs are serviced out.

    So I think that there will be no IRQ delays or usage faults. The real problem is the preemption that can destroy the task contexts and the use of PendSvc is the correct solution. Another solution is to lower enough the SYSTICK priority.
    There is one more thing about the priorities. Sometimes you need to call protected system function (SVCs) not only from user tasks but also from ISRs. This means that the SVC exception must have a mid-priority and all kernel-aware IRQs must have lower priority otherwise they will end up with usage fault if they use the SVC instruction.  Then we will have
    - "fast" IRQs
    - SVC
    - kernel aware IRQs
    - SYSTICK
    - PendSV
    - user tasks

    Miro
Children
No data