This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Final packet corruption/loss during large file transfer between 2 nRF52840's

I am currently trying to send indefinitely large files over BLE. To do this I have a central and peripheral application running between 2 nRF52840's (one peripheral, one central). The peripheral sends data via sd_ble_gatts_hvx.

When I am sending files that are small enough to fit inside one pre-allocated file buffer (size = 1000) I have no issue. The buffer is modulated into packets of NRF_SDH_BLE_GATT_MAX_MTU_SIZE (or less for the final packet) and the central application receives all the correct bytes.

When I am sending files that are too large for to fit inside one pre-allocated buffer, I send each buffer individually, i.e. I will modulate the file buffer into packets of NRF_SDH_BLE_GATT_MAX_MTU_SIZE (with the exception of the final packet which may be smaller). Once the central node has confirmed it has received all of the buffer's data and written it to an SD card, I will read new data into the peripheral's file buffer and begin the process again.

This method works fine until the very last packet of the very last file buffer. For some reason the central application receives a jumble of incorrect bytes. This packet is the correct length.

An exception to this failure is if the file can be modulated by NRF_SDH_BLE_GATT_MAX_MTU_SIZE with no remainder (i.e. never sends a packet smaller than NRF_SDH_BLE_GATT_MAX_MTU_SIZE).

If anyone has had a similar issue to this, please point me in the right direction.

Edit 2021-04-07: My application is based on the image transfer demo, which can be found here. I use ble_its_send_file to send my files from the peripheral. The central application then receives a data event and processes the incoming data.

Parents
  • Hi Lawrence

    Do you see any helpful information as to what's going on if you try debugging your application? Do you know how long (the size) the final packet is supposed to be every time or not? It could be that the final packet is parsed incorrectly or similar.

    Are you able to provide a sniffer trace of the communication between these devices so that we can get an idea of what's going on on-air? If you have a spare nRF52 device you should be able to use the nRF Sniffer for this purpose.

    Best regards,

    Simon

  • Hi Simonr,

    I had been working on this for a long time before I posted here. Shortly after I discovered that something was being overwritten from the peripheral end.

    For some reason NRF_LOG_INFO was able to display that the correct packet had been passed into the softdevice queue (this would show after the central application confirmed packet received). In actuality, the packet passed in would be overwritten/reset. I'm still a little unsure why it would only do this under the specific conditions I listed above, but I was able to solve this by blocking the peripheral function from continuing until it received a notification from the central node, where as previously I had not.

Reply
  • Hi Simonr,

    I had been working on this for a long time before I posted here. Shortly after I discovered that something was being overwritten from the peripheral end.

    For some reason NRF_LOG_INFO was able to display that the correct packet had been passed into the softdevice queue (this would show after the central application confirmed packet received). In actuality, the packet passed in would be overwritten/reset. I'm still a little unsure why it would only do this under the specific conditions I listed above, but I was able to solve this by blocking the peripheral function from continuing until it received a notification from the central node, where as previously I had not.

Children
No Data
Related