Firmware transfer over BLE for another MCU

[ShuMan]

Hi,

For our application, we need to transfer binary (.bin) file from Phone and nRF5340 over BLE and store it into the SD card. Later, another MCU will read the file and update its firmware.

I went through two other queries query_1 and query_2, but those are for transferring data over UART. However, I want to store the file first on an external SD card connected to the SoC, rather than directly transmitting over UART.

I cannot find any example for the same in nRF Connect SDK V2.0.0. Please let me know if I can use any example or a can follow a procedure.

Thanks

[Simon]

Take a look at the samples peripheral_uart and central_uart. These samples demonstrates how to transfer data between two devices using Bluetooth and the RX and TX characteristics.

Best regards,

Simon

[ShuMan]

Hi Simon,

I have tried these examples before. However, the transmission speed is very slow for me (1 - 1.5 KBps). Please suggest how to increase the transmission speed.

Thanks

[Simon]

Check out the Throughput example: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/nrf/samples/bluetooth/throughput/README.html 

[ShuMan]

Thanks, I will check it.

[ShuMan]

Hi,

I need a small help in this case which is related to nRF5340 freezing when transferring data continuously with faster rate from a central device (Mobile app).

So previously I went through the throughput and peripheral_uart examples and able to received large amount of data at faster rate. However, I see the nRF5340 freezes after certain ble writes. In every iteration, I try to send 491 bytes data. 

Some of the used configurations are as below:

CONFIG_BT_BUF_ACL_RX_SIZE=502

CONFIG_BT_ATT_PREPARE_COUNT=2

CONFIG_BT_L2CAP_TX_BUF_COUNT=10

CONFIG_BT_L2CAP_TX_MTU=498

CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y

CONFIG_BT_CONN_TX_MAX=10

CONFIG_BT_BUF_ACL_TX_COUNT=10

CONFIG_BT_BUF_ACL_TX_SIZE=502

CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

CONFIG_BT_CTLR_PHY_2M=y

CONFIG_BT_CTLR_RX_BUFFERS=2

CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=4000000

The code implementation is as below.

void write_fs(void *write_data, ssize_t len)
{
	fs_seek(&bleRxFilePtr, 0, FS_SEEK_END);
    fs_write(&bleRxFilePtr, write_data, len);
    return;
}

static void bt_receive_cb(struct bt_conn *conn, const uint8_t *const data, uint16_t len)
{
    LOG_WRN("ble_rx_data: %s",data);

    uint8_t *ble_rx_data = (uint8_t *)data;
    uint16_t ble_rx_data_len = len;


    if('!' == ble_rx_data[0]) {
        /* Write data received to the SD card */
        write_fs(ble_rx_data + 1, len - 3);
    }
    else if('&' == ble_rx_data[0]) {
        update_connection_parameters();
	    request_mtu_exchange();
	    request_data_len_update();
	    request_phy_update();
    }
    return;
}

The logs for PC & LR register are as below;

Thanks

[Sigurd Hellesvik]

ShuMan said:

However, I see the nRF5340 freezes after certain ble writes

Do these BLE writes have anything in common?
Are there other BLE writes which this never happens on?

How often does this happen?

[ShuMan]

Sigurd Hellesvik said:

Do these BLE writes have anything in common?

Observing this while sending around 10 MB data continuously in small packet from mobile app to nRF5340, where each packet of size 495 bytes. I have decided the packet size due to CONFIG_BT_L2CAP_TX_MTU=498 in prj.conf. The mobile app sends 495 bytes continuously without any delay in between. As soon as the data with'$' at the start is received, it is written to SD card. Approximately after few thousand writes, the issue occurs.

Sigurd Hellesvik said:

Are there other BLE writes which this never happens on?

Another BLE write which is used to trigger below functionality, issue doesn't occur. These writes happen only to update connection related aspects.

update_connection_parameters();
request_mtu_exchange();
request_data_len_update();
request_phy_update();

Sigurd Hellesvik said:

How often does this happen?

With many thousand writes, issue occurs.

[Sigurd Hellesvik]

So it is either the BLE, the SD card writing or the combination of these.
Can you try to write dummy data without BLE to the SD card some thousand times and see if this happens?
Then receive data from BLE the same amount and not write data to SD card, but discard it instead, and see if this happens?

With this, we can find if it is an SD Card or BLE specific issue.

Edit: A collegua also suggests this:
" Sounds a bit like a flow control issue, yes. Ideally you should stop processing packets from the Bluetooth stack if your local buffers fill up, then the SDC will start NAKing incoming data. "

[ShuMan]

Sigurd Hellesvik said:

" Sounds a bit like a flow control issue, yes. Ideally you should stop processing packets from the Bluetooth stack if your local buffers fill up, then the SDC will start NAKing incoming data. "

Is there a method to let mobile application tell that nRF5340 side local buffers already filled and it has to wait?