Interrupt handler question for kinetisKE04 i2c driver

[jun1]

Thank you for all your help.

In the SDK_2_11_0_MKE04Z128xxx4 driver fsl_i2c.c there is the following interrupt handler.
Will something bad happen if I remove this last DSB instruction?　On the contrary, what does it prevent?

static void I2C_TransferCommonIRQHandler(I2C_Type *base, void *handle)
{
　　uint8_t tmpS = base->S;
　　uint8_t tmpC1 = base->C1;

　　/* Check if master interrupt. */
　　if ((0U != (tmpC1 & I2C_C1_MST_MASK)) || (0U != (tmpS & (uint8_t)kI2C_ArbitrationLostFlag)))
　　{
　　　　s_i2cMasterIsr(base, handle);
　　}
　　else
　　{
　　　　s_i2cSlaveIsr(base, handle);
　　}
　　__DSB();
　　}

}

[jun1]

Thank you for your advice.

OK. Leave it as it is.

Also, I totally agree with the following words.

"Theory rarely works in the real world ..."

A good day

[bobpaddock · Accepted solution]

Far safer to leave it.  It assures that everything is completed before the interrupt exits.
Taking it out leaves the system open to 'once in a blue moon', hair pulling, kid of race condition crashes.

For M4 based processors is is required due to errata:

* // Add for ARM errata 838869, affects Cortex-M4, Cortex-M4F Store
* // immediate overlapping exception return operation might vector
* // to incorrect interrupt

In theory is is not required on the M0(+) cores.
Rarely does theory work in the Real World...

/*
* Data Synchronization Barrier (DSB): Ensures that all explicit data
* memory transfer before the DSB are complete before any instruction
* after the DSB is executed.
*
* Ensure effects of an access to SCS take place before the next
* operation
*
* Ensure memory is updated before the next operation, for
* example, SVC, WFI, WFE.
*
* Vector table changes:
* If the program changes an entry in the vector table,
* and then enables the corresponding exception, a DSB
* instruction should be used between these two
* operations. This ensures that if the exception is
* taken after being enabled the processor uses the new
* exception vector. If the updated vector table is
* required immediately, for example if an SVC
* immediately follows an update to the SVC table entry
* via a store, then a DSB is also required.
*
* Memory Map modifications:
* If the system contains a memory map switching
* mechanism then use a DSB instruction after switching
* the memory map in the program. This ensures subsequent
* instruction execution uses the updated memory map, if
* the memory system makes the updated memory map visible
* to all subsequent memory accesses.
*
* Note:
* An ISB or an exception entry/return is required
* to ensure that the subsequent instructions are
* fetched using the new memory map.
*
* The memory barrier instructions, DMB and DSB, can be used to ensure
* that the write buffer on the processor has completed its operation
* before subsequent operations can be started. However, it does not
* check the status of the bus level write buffers. In such cases, if
* the system is based on AHB or AHB Lite, you might need to perform a
* dummy read through the bus bridge to ensure that the bus bridge has
* completed its operation.
*
* The Cortex-M0 processor (r0p0) and the Cortex-M0+ processor (r0p0)
* do not include a write buffer in their processor bus interface.
*
* Architecturally, a DSB instruction should be used after changing
* the VTOR if an exception is to be generated immediately and should
* use the latest vector table setting.
*
* In Cortex-M3, Cortex-M4 and Cortex-M0+ processors, accesses to the
* SCS have the DSB behavior, so there is no need to insert the DSB
* instruction.
*
* A DSB is required before generating self-reset to ensure all
* outstanding transfers are completed. The use of the CPSID I
* instruction is optional.
*/

// The code I use:
//The 'memory' clobber barrier prevents "code motion".

#define ATTR_NO_INSTRUMENT_FUNCTION __attribute__( ( no_instrument_function ) )

static inline ATTR_NO_INSTRUMENT_FUNCTION void sync_barrier_data( void )
{
__asm__ __volatile__ ("dsb");
__asm__ __volatile__ ("" ::: "memory");
}