• Locked Locked
  • Replies 8 replies
  • Subscribers 119 subscribers
  • Views 10913 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 Memory management fault recovery

sam sun
Note: This was originally posted on 2nd June 2011 at http://forums.arm.com

Hi, is the Cortex-M3 supposed the user to do mannual instructions to recovery from the memory management fault handler?

After enable the MPU feature on my Cortex-M3 processor and stepped into the illegal access instruction, the MMF exception would generated as expected. But after executing of the normal MMF exception handler, the program would go back to the illegal access instruction again! We have inspected the stack of entering the MMF exception, the PC pushed is exactly the illegal instruction, that would be the cause of the loop. So is this the definition of the Cortex-M3 familiy?

The other exceptions would normally adjust the PC value to the next instruction before entering the exception, liked system tick or other IRQs.

BR
Parents
  • in reply to Joseph Yiu

    Joseph,

    Thanks. I don't like the idea of skipping the faulty instruction, either.

    In case that M3 is handling multiple tasks within a queue, and it gets stuck (bus fault by read access to system memory) within one task.

    Is it possible for M3 to abort the remaining operations after limited retries for current task gracefully and move forward to handle next task in the queue? or M3 has to be stalled for a system reset.

    Kevin

Reply
  • in reply to Joseph Yiu

    Joseph,

    Thanks. I don't like the idea of skipping the faulty instruction, either.

    In case that M3 is handling multiple tasks within a queue, and it gets stuck (bus fault by read access to system memory) within one task.

    Is it possible for M3 to abort the remaining operations after limited retries for current task gracefully and move forward to handle next task in the queue? or M3 has to be stalled for a system reset.

    Kevin

Children
  • Arm Employee Badge in reply to Kevin

    Hi Kevin,

    You can possibly implement this in your bus fault handler.

    For example, create a static variable to count the number of retry, and if it exceed the limit then signal to the embedded OS to kill the task. You might also able instruct the OS to restart the task, but it depends on the OS you use. Or potentially move the task into a suspended queue.

    But whether the system can still function correctly after the task is killed and restarted is application dependent.

    Regards,

    Joseph

    Sent from my iPad