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

Is a DMB required between loading BASEPRI and storing BASEPRI_MAX?

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!

Parents
  • 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.

    1. Let's say the last instruction in an ISR is `msr BASEPRI_MAX #3`, and at the same time as this instruction is issued, an interrupt of priority 3 arrives. Is it possible for `msr BASERPRI_MAX #3` to be executed after the ISR for the interrupt of priority 3 enters? 
    2. Is the order of special register accesses maintained across exceptions? From your earlier answer I'm guessing yes, but just want to clarify. So, if in the example mentioned in the previous bullet the ISR of some priority 3 IRQ enters, and the first instruction there is `mrs r0, BASEPRI`, is the outstanding `msr BASEPRI_MAX #3` guaranteed to execute first, even though it was issued from an ISR of potentially different (logically lower) priority? Is this behavior at all different between Cortex M4 and M7?
Reply
  • 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.

    1. Let's say the last instruction in an ISR is `msr BASEPRI_MAX #3`, and at the same time as this instruction is issued, an interrupt of priority 3 arrives. Is it possible for `msr BASERPRI_MAX #3` to be executed after the ISR for the interrupt of priority 3 enters? 
    2. Is the order of special register accesses maintained across exceptions? From your earlier answer I'm guessing yes, but just want to clarify. So, if in the example mentioned in the previous bullet the ISR of some priority 3 IRQ enters, and the first instruction there is `mrs r0, BASEPRI`, is the outstanding `msr BASEPRI_MAX #3` guaranteed to execute first, even though it was issued from an ISR of potentially different (logically lower) priority? Is this behavior at all different between Cortex M4 and M7?
Children
  • Hi Ramzyo,

    Thanks for your kind words.

    1. No.

    In Armv7-M architecture (https://developer.arm.com/docs/ddi0403/latest ) Section B5.2.3

    Visibility of changes in execution priority resulting from executing an MSR instruction
    If execution of a MSR instruction:
    •Increases the execution priority, the MSR execution serializes that change to the instruction stream.
    •Decreases the execution priority, the architecture guarantees only that the new priority is visible to instructions executed after either executing an ISB, or performing an exception entry or exception return.

    (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

    regards,

    Joseph