Cortex-M3 Memory management fault recovery

Hi Kevin,

Memory Management Faults are precise (not imprecise as in your message). So if you just have a return in your fault handler, it will retry the same instruction again.

For parity bit error / ECC, you can generate a bus fault when an error is detected. This trigger the bus fault exception (not Memory Management Fault).

If you have ECC in your system, you can design your system to correct the error in the memory and then when the handler return, the read access is retry and hopefully it will have correct data the second time.

A bus error response for Write operations can be precis or imprecise, but normally you don't generate parity error or ECC error during writes because the write data from the processor is assumed to be correct.

If is in theory possible to design your handler to skip one instruction, but the handler will need to check if the bus fault is precise or imprecise first, and also use software to decode if the faulting instruction is 16-bit or 32-bit so that the return program address can be calculated. The handler will need to extract the faulting program counter address from the stack frame (see HardFault handler section). However, if the fault is caused by a stack corruption you might not be able to do that.

Then finally I would question if skipping a faulting instruction is right. If a bus fault is reported, skipping the faulting instruction doesn't mean the remaining part of the program can continue correctly. As you say, all read operations on Cortex-M3/M4 are precise so you can use bus fault to handle parity / ECC error.

Hope this helps.

regards,

Joseph

Hi Kevin,

Memory Management Faults are precise (not imprecise as in your message). So if you just have a return in your fault handler, it will retry the same instruction again.

For parity bit error / ECC, you can generate a bus fault when an error is detected. This trigger the bus fault exception (not Memory Management Fault).

If you have ECC in your system, you can design your system to correct the error in the memory and then when the handler return, the read access is retry and hopefully it will have correct data the second time.

A bus error response for Write operations can be precis or imprecise, but normally you don't generate parity error or ECC error during writes because the write data from the processor is assumed to be correct.

If is in theory possible to design your handler to skip one instruction, but the handler will need to check if the bus fault is precise or imprecise first, and also use software to decode if the faulting instruction is 16-bit or 32-bit so that the return program address can be calculated. The handler will need to extract the faulting program counter address from the stack frame (see HardFault handler section). However, if the fault is caused by a stack corruption you might not be able to do that.

Then finally I would question if skipping a faulting instruction is right. If a bus fault is reported, skipping the faulting instruction doesn't mean the remaining part of the program can continue correctly. As you say, all read operations on Cortex-M3/M4 are precise so you can use bus fault to handle parity / ECC error.

Hope this helps.

regards,

Joseph

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

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