f_write/f_close cause BLE disconnect

[snowfield]

Hardware: nrf52832

SDK: 16.0.0 with FreeRtos, 

Softdevice: S132 7.0

I set configMAX_PRIORITIES to 5 and modified nrf_sdh_freertos_init to set BLE task priority to 4.

My sd card maintain task priority is set to 2.

For BLE NUS service:

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(20, UNIT_1_25_MS) /**< Minimum acceptable connection interval (20 ms), Connection interval uses 1.25 ms units. */
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(75, UNIT_1_25_MS) /**< Maximum acceptable connection interval (75 ms), Connection interval uses 1.25 ms units. */
#define SLAVE_LATENCY 0 /**< Slave latency. */
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS) /**< Connection supervisory time-out (4 seconds). */

The NUS service and SD card function works fine when test them separately. But if Operate SD card during NUS connection, I got disconnect with reason:0x8

I have tried to enlarge INTERVAL to 120ms/175ms, also tried to change SLAVE_LATENCY to 4. Problem still exist.

I searched internet and NRF Dev Zone, found some similar question, but none of them can resolve my problem. So I have to raise a new question here. 

 

[Simonr]

Hi

Lowering the BLE task priority and giving other tasks priority over it will cause the radio to be interrupted and cause disconnections. You should revert any changes you have made to the BLE task priority and set the SD card tasks to a lower priority so that it doesn't interfere with the radio at all. The default BLE task and LOG task priorities should be left alone, as they require the highest priority available. Please try setting your "custom tasks" to 4, 5, and 6 for example as that should prevent the radio from being interrupted.

Best regards,

Simon

[snowfield]

Dear Simonr:

    Sorry I am little bit confused: On freeRTOS, the bigger number should mean higher priority. That's why I modified BLE task priority to 5 and my own task's priority is 2,3.

    Do you mean on NRF freeRtos, bigger number means lower priority? 

    I think my understanding is correct because I can see the IDLE task's priority is 0