How to use critical region and app_uart

[Masa Kawa]

I implemented UART communication as follows, but occasionally the same data is sent twice.

1. Enter the critical region (app_util_critical_region_enter).
2. Store the transmission data in the TX FIFO until it is full (app_uart_put).
3. Exit the critical region (app_util_critical_region_exit).
4. When the APP_UART_TX_EMPTY event occurs, if there is any remaining transmission data, store it in the TX FIFO (app_uart_put). (If there is no remaining data, the transmission ends.)

I intend to stop the event occurrence between steps 1 and 3, but in reality, it seems that the event in step 4 is running during the process in step 2, causing the same data to be stored in the TX FIFO.

In the above design, is it not possible to stop the event occurrence?

SDK:nRF5 SDK 15.3.0

SoftDevice:s132_nrf52_6.1.1

[Masa Kawa]

Hello, Thank you for your reply.

For example, if an event occurs and modifies the shared buffer while it is being copied in the main loop, the atomicity of the buffer could be compromised. Therefore, to ensure atomicity for shared resources (such as buffers) that are accessed by both the main loop and events, I use a critical region when accessing from the main loop.

The same concept applies to BLE and SPI data reception events. The received data is copied to the shared buffer on the event side. In the main loop, a critical region is used when accessing the shared buffer.

In the above case, does the event suppression by the critical region also not function properly?

[Edvin]

Ok, I guess that makes sense. At least if you risk the events changing the part of the buffer that is being transmitted. If you use some sort of ring buffer, or a double buffer, it can be avoided, though. Also, I don't know how much time you spend actually transmitting this buffer. It depends on the buffer size and the baud rate. If it takes a really long time, you risk loosing data other places, e.g. if the SPI data events are suppressed for too long, you may loose bytes there.

BR,
Edvin

[Masa Kawa]

I understand your response.

If it takes a significant amount of time, such as when the buffer size is large, I will consider methods other than critical regions.

Thank you for your response.