Revisions Affected:

Revision B

Details:

Configurations Affected:

This erratum only affects systems where writeable memory locations can exhibit more than one wait state (system SRAM does not have wait states).

The Arm®Cortex®-M4F processor includes a write buffer that permits execution to continue while a store is waiting on the bus. Under specific timing conditions, during an exception return while this buffer is still in use by a store instruction, a late change in selection of the next interrupt to be taken might result in a mismatch between the interrupt acknowledged by the interrupt controller and the vector fetched by the processor.

Conditions:

• The handler for interrupt A is being executed.
• Interrupt B, of the same or lower priority than interrupt A, is pending.
• A store with immediate offset instruction is executed to a bufferable location:

  
  STR/STRH/STRB <Rt>, [<Rn>,#imm]
  STR/STRH/STRB <Rt>, [<Rn>,#imm]!
  STR/STRH/STRB <Rt>, [<Rn>,#imm]
  

• Any number of additional data-processing instructions can be executed.
• A BX instruction is executed that causes an exception return.
• The store data has wait states applied to it such that the data is accepted at least two cycles after the BX is executed.
  • Minimally this is two cycles if the store and the BX instruction have no additional instructions between them.
  • The number of wait states required to observe this erratum needs to be increased by the number of cycles between the store and the interrupt service routine exit instruction.
• Before the bus accepts the buffered store data, another interrupt C is asserted which has the same or lower priority as A, but a greater priority than B.

Implications:

The processor should execute interrupt handler C, and on completion of handler C the processor should execute the handler for B. If the previously listed conditions are met, then this erratum results in the processor erroneously clearing the pending state of interrupt C, and then twice executing the handler for B. The first time the handler for B is executed it will be at the priority level for interrupt C. If interrupt C is pended by a level-based interrupt that is cleared by C's handler then interrupt C will be pended again after the handler for B has completed and the handler for C will be executed. If interrupt C is level based, then this interrupt will eventually become re-pending and subsequently be handled. If interrupt C is a single pulse interrupt, there is a possibility that this interrupt will be lost.

This bug is triggered in a rare condition. In cases where STORE experiences more than 2 wait cycles, workarounds must be used by the software developer.

• This erratum does not apply for TI-RTOS interrupts, which ensures that no store with immediate offset occurs within the last 5 instructions of the interrupt routine. See the following files included in all SDKs for further implementation details:
  • kernel/tirtos/packages/ti/sysbios/family/arm/m3/Hwi_asm*.sv7M
• Zero-latency interrupts in TI-RTOS (bypassing the kernel) and the no-RTOS examples in the SDK are affected by this erratum.

Workarounds:

Software not using the Memory Protection Unit (MPU):

For software not using the Memory Protection Unit (MPU), the workaround can be to disable CPU write buffering (register CPU_SCS.ACTLR.DISDEFWBUF) at the cost of significantly reduced execution speed.

All other cases (recommended workaround):

Ensure a DSB instruction occurs between the store and the BX instruction. For exception handlers written in C, this can be achieved by inserting the appropriate set of intrinsics or inline assembly just before the end of the interrupt function, for example:

ARMCC:

...

__schedule_barrier(); __asm{DSB}; __schedule_barrier(); }

GCC:

...

__asm volatile (“dsb 0xf” ::: “memory”); }