Receiving MTU errors when trying to conduct OTA DFU

[tjhasan]

I'm currently working on a program that automates the Legacy DFU procedure and I'm running into some strange issues with writing to the DFU characteristics.

On the nRF Connect Mobile app, it is possible to write to the DFU characteristic "DFU Packet" by manually typing in the bytes to be sent with the option "bytearray" chosen. On the mobile app, I type in the full, valid write value to be sent to the "DFU Packet" characteristic and there is no issue.

However, on my desktop application, when attempting to write the same, valid value to the "DFU Packet" characteristic, I receive an error that states:

"Data length must be less than MTU size minus 3 (header): MTU: 23 bytes. Data being written: 28 bytes"

My question is, why am I receiving this error and how could I go about mitigating it? If the MTU size not changeable, how do I go about sending the data I want over multiple packets?

Here are some more details on my setup:

• Mobile Legacy DFU:
  • Central: Android Smartphone running latest version of nRF Connect Mobile
  • Peripheral: nRF52 DK running an example firmware that supports Legacy DFU
• Desktop Legacy DFU
  • Central: nRF52 DK used as a BLE connector
  • Peripheral: (different) nRF52 DK running an example firmware that supports Legacy DFU

Note that the firmware image that I am attempting to send is the same regardless of mobile or desktop. Any help would be greatly appreciated!

[Vidar Berg]

Hello,

Legacy DFU did not have support for long ATT MTUs, so the payload was effectively limited to 20 bytes per write (23 byte MTU - 3 Byte header). In other words, the PC client app will have to split the data into 20 bytes packets before sending.

I'm not sure why you didn't see error when you sent the DFU packet from your phone though. Did you use the same packet length? If so, I guess the phone must have split the packet across multiple on-air BLE packets (i.e. performed what's known as a long write - GATTC Characteristic or Descriptor Value Long Write). But that is an inefficient way to transfer data and is something you should avoid if you care about throughput performance. It's faster to send GATT write commands 20 bytes at a time.

Best regards,

Vidar

[tjhasan]

I see. I don't really have access to the source code for the nRF Connect Mobile app so I can't comment on why I didn't receive the error on my phone. I did indeed use the same packet length.

I guess my follow-up question would be how would I send write commands 20 bytes at a time? For example, if I had a 40 byte packet I wanted to send, I would have to send it as 2 separate 20 byte write commands. But how do I tell the GATT server that the first 20 bytes is NOT the end of the data I want to write? How does the GATT server know how much data to expect from a given write command?

[Vidar Berg]

tjhasan said:

But how do I tell the GATT server that the first 20 bytes is NOT the end of the data I want to write?

You don't have to, the packets will be re-assembled by DFU target as they are received. And the bootloader knows how many bytes/packets to expect because of the DFU protocol (DFU Protocol: BLE DFU Profile).