Hi,
I have a question regarding BASEPRI, BASEPRI_MAX, and DMBs as they relate to both the V7-M and V7E-M architectures.
Let's say I have the following assembly,
// stuff mrs r0, BASEPRI msr BASEPRI_MAX, #3 // more stuff
Is it necessary to put a DMB between the two instructions so that the processor doesn't reorder the memory accesses? After reading Chris Shore's article here and reading through the data sheet of the MCU that I'm working with, my understanding is that a DMB isn't necessary because the special registers are 'strongly-ordered' memory (or are they 'device memory'? Was a little confused about this). That being said, here's where my confusion comes in - BASEPRI and BASEPRI_MAX have different encodings in their system instructions (section B5.1.1 of the ARM v7-M Architecture Reference Manual [ARM DDI 0403E.b ID120114]). For a mrs instruction, BASEPRI_MAX is aliased to BASEPRI, however, this is not the case for a msr instruction. So, if the system instructions are different, does this imply that the processor treats the two instructions above as independent, and is therefore free to execute them in any order it pleases?
Thanks!
There is no need to add memory barrier instruction between these two instructions. Special register accesses with MRS and MSR are always in order. (In the case of a longer pipeline design like Cortex-M7, it could means it take multiple clock cycles as they cannot be dual issued).
BASEPRI and BASEPRI_MAX are actually same register, but when BASEPRI_MAX is specified, the update of BASEPRI is conditional: only when the new level is higher priority (smaller number) then current level.
Hi Joseph, thanks for the reply. Big fan of your books, very informative and a great companion to Cortex-M development.
Ok, thanks for your clarification. Two follow-up questions.
Hi Ramzyo,
Thanks for your kind words.
1. No.
In Armv7-M architecture (https://developer.arm.com/docs/ddi0403/latest ) Section B5.2.3
(it means if the MSR instruction set BASEPRI to 3, the interrupt of priority level 3 cannot take place, or if the processor already started accepting the interrupt, the MSR instruction must be abandoned and restart after the ISR completed).
2.
Yes, the order is maintained across exceptions.
It is hard to follow the scenario you described, but as mentioned in (1), if the processor enter an ISR with priority level 3, BASEPRI should not be set to 3. It should work for both Cortex-M4, Cortex-M7, Cortex-M33 and Cortex-M35P.
regards,
Joseph
Thanks Joseph.
Does "Increases the execution priority" mean set BASEPRI to a numerically lower value (e.g. BASEPRI is 4, then set it to 3), or the other way around?
Regarding (1) - in the case of decreasing execution priority, why is an ISB necessary to guarantee visibility of the new priority "...the new priority is visible to instructions executed after either executing an ISB..." ? Shouldn't the fact that special register accesses with `mrs` and `msr` are always in order guarantee this without the need for an ISB?
"Increase priority" - yes, it means the priority level value is decreased (except to 0, which means disabled BASEPRI).
In the case of MSR followed by MRS, or other way round, there is no need to use ISB.
But if you have MSR to decrease masked interrupt level priority, then execute SVC, in that case the ISB would be needed before the SVC. Otherwise the SVC could already been decoded and the NVIC could "think" that the SVC should be blocked because the priority level for the SVC was masked.
More information about memory barrier usage requirements can be found in:
developer.arm.com/.../application-note-321-arm-cortex-m-programming-guide-to-memory-barrier-instructions
Thank you!