Questions about "read-modify-wrte" register operation

[freei]

Hi!

The following Uart driver comes from SDK_2.x_FRDM-K64F(SDK Version 2.11.0); In this SDK, similar "read-modify-wrte" operation codes for registers like UART_C2 are very common, but I have some questions about this, please help to answer them, thank you!

        /* Disable and re-enable the global interrupt to protect the interrupt enable register during * read-           modify-wrte. */

        irqMask = DisableGlobalIRQ();

        base->C2 &= ~(uint8_t)UART_C2_ILIE_MASK;

        EnableGlobalIRQ(irqMask);

My questions are:

1. What is the purpose of the code "DisableGlobalIRQ ... EnableGlobalIRQ(irqMask)")? I think that disabling the global interrupt is to prohibit thread switching, thus ensuring the reliability of C2 bit operation and avoiding errors caused by multiple threads operating C2 registers together. Is my understanding correct?

2. If no other thread modifies the C2 register, can the operation("DisableGlobalIRQ ... EnableGlobalIRQ(irqMask)") here be canceled? Will there be other unpredictable errors?

Looking forward to your reply, thanks!

[EdwinHz]

Hi @freei,

Yes, you understanding is correct. It’s important to make sure that the he control registers (C1, C2 and C3) get asserted correctly in order to ensure the proper functionality of the UART module. C1 is only modified on the initialization function, which is meant to be called before the main processes of the application. C2 and C3 can be modified during the main application process, which is why you will find modifications of these two registers to be accompanied with a DisableGlobalIRQ() to ensure that these registers are asserted correctly and that no other interruption will execute during the modification of these registers.

That said, we highly encourage you to follow this process when implementing your own uart driver. Avoiding these safety features might lead to an improper assertion or modification of the control registers, which will lead to an inadequate or unexpected implementation of the drivers.

BR,

Edwin.