sometimes writing is completed too slowly during BLE communication.

[hiroiwas]

Hello.

In the BLE software under development, the device uses nRF52840 and uses s140 v7.2.0 or v7.3.0.

While using BLE communication, I am building a system that receives the firmware updater via UARTE and stores it in flash via a modified DFU.

In order to prevent UARTE transfer from being lost during flash writing, I use nrf_drv_uart_rx_abort() to stop reception (RTS inactive) when requesting fstorage write, and restart reception (RTS active) with nrf_drv_uart_rx() when writing is completed.
However, during BLE communication, a reception interruption period of several 100 ms may occur due to the fstorage schedule by the timeslot API.

As a result, a situation has arisen in which the transfer interval from the UART destination cannot be maintained.

What I want to do is to make RTS inactive only during Flash access when it cannot receive reception, but is this possible with fstorage I/F via softdevice?

If it is not possible, I would like to stop the BLE timeslot from the wtite request to the completion of the write.If I stop scan and advertise except during connection, will it be scheduled in fstorage?

If UART reception has to wait due to BLE communication, the idea is to stop the BLE time slot for a short period while writing and activate RTS quickly.

Best regards.

[Einar Thorsrud]

Hi,

Writing to flash is not possibel while the radio is active. But UART communication should not be an issue.

What I want to do is to make RTS inactive only during Flash access when it cannot receive reception, but is this possible with fstorage I/F via softdevice?

Why is this? The data received over UART must be stored in RAM first (the RX buffer must reside in RAM), so there should not be any issue receiving data over UART? But subsequently coping this data to falsh will not be possible until the radio operation has completed (and scheduling of this is handled by the SoftDevice). Moreover, the UART driver handles flow control (RTC/CTS) automatically for you, so I am having some problems understsanding if or why you want to handle this manually and what problem you are trying to solve by doing so?

[hiroiwas]

Hello,  Einar.

The problem was that in situations where a large number of timeslots were allocated to BLE, such as when connecting, the flash write completion was delayed and the next write request from the UART could not be accepted.
As a countermeasure, I used software control to disable RTS between the flash write request and write completion, but the RTS disable time became longer than expected, which led me to this question.

As you pointed out, it seems possible to suppress reception while the CPU is stopped due to writing using only hard flow RTS.
Based on this, I was able to solve this problem by buffering the next write request received during a write and being able to accept multiple write requests.

Thank you.