ISB isntructions on Cortex-M4 port

npoulokefalos wrote on Saturday, March 11, 2017:


I have a question for the ISB instruction usage in GCC ARM_CM4F port [FreeRTOS v9.0.0].

It is used inside xPortPendSVHandler() after:

"    mrs r0, psp                            \n"
"    isb    

and after:

"    msr psp, r0                            \n"
"    isb    

In constrast, ISB is not used in the GCC ARM_CM4_MPU port when PSP is loaded/stored.
Is there any reason for why this is required in one case and not to the other? I just need to verify that i am not missing something.

I am also curious about the ISB in the fist scenario, after “mrs r0, psp”. Why it is needed?

rtel wrote on Sunday, March 12, 2017:

The ISB instructions are required to be in strict compliance with the ARM Cortex-M specification. However for a long time actual purchasable implementations of the architecture did not, in practice, need the instructions. That changed a little while back, especially when the Cortex-M7 came out, and as the Cortex-M4F port is also used on Cortex-M7 chips the Cortex-M7 port was updated accordingly. The instructions should also be included in the MPU port too, as they become more relevant, and will be added.

npoulokefalos wrote on Sunday, March 12, 2017:

Thanks for the reply,

To my knowledge, at least for te M4 port, the ISB would be required when MSR is used on the stack pointer currently used. Etc “MSR msp, r0” from whithin an ISR with subsequent push/pop instructions or in thread mode if MSP is also used there.

I am not familiar with Cortex M7, but is there any actual case where “MRS r0, psp” (not MSR) would require an ISB? Or it is just used after MSR/MRS in any case – even if next instructions does not require it, just to be inline with the specification?

rtel wrote on Sunday, March 12, 2017:

You may be right, that it is not required when moving from a special
purpose register into a general purpose register. Having a look at the
the source code I can only see one place where an MRS is followed by an
ISB, and that is at the start of the PendSV handler.