Hi,
Developing by NCS SDK, We found it will take 20 minutes by using mcumgr(on MacBook-pro) to BLE OTA 178KB image to nRF52840 Product Board's external SPI FLASH. it success, but very slow.
is it normal for such a low speed ? Or we make any mistake ?
Best Regards
Frank
Hi Frank,
Could you please capture a sniffer trace ? With the sniffer we would be able to see what happened via BLE when you do FOTA. We need to get to know where the bottle neck is, either in BLE or in the flash writing in the external SPI Flash.
Usually for normal FOTA to internal flash from a phone, I'm seeing about 1-2 minutes with a firmware of 200kB.
Could you please try testing the same firmware update from an Android/iOS phone ? (using nRF Connect app)
Hi, Hung :
About your words : Usually for normal FOTA to internal flash from a phone, I'm seeing about 1-2 minutes with a firmware of 200kB
yes, I got the same result if moving the OTA flash back to the internal flash of nrf52840.
However, if using the external SPI Flash, the OTA time will be 10x, which is 20 minutes. it is really very slow because user must keep their phone on for such a long time in order to do the OTA.
I also move my code to the nrf52840 EVB, nrf52840dk_nrf52840, and get the same slow performance if OTA to the external SPI flash of 52840 EVB.
Is there any method to improve the performance ? Please kindly help us on this issue ! Thanks a lot !
Best Regards
Frank Wang
Hi Frank,
Could you give more information on how you enable FOTA via external flash ?
Have you managed to capture the sniffer trace ? With that we can check if the issue was with BLE or it's the bottle neck with the external SPI.
Hi Hung :
By nRF sniffer, I capture the sniffer record of
1,) OTA to internal Flash
2,) OTA to external SPI flash
Please kindly check the attached 2 Wireshark files. Please let me know if you need more info. Thanks for your help !
NCS OTA Wireshark_External_SPI_Flash.pcapngNCS OTA Wireshark_Internal_Flash.pcapng
Best Regards
Frank
Hi Frank,
I talked to the R&D team and they agreed that the SPI could be the bottle neck here and they are working on a solution. It may take 1-2 months before we can have a patch out.
For now, our suggestion is to try increasing the packet you can send on each BLE packet (increase DLE and ATT_MTU)
The reason is that each L2CAP fragment is allocated one buffer, and SMP module only has 4 buffers.
Please have a look at the throughput example \nrf\samples\bluetooth\throughput.
Hi Frank,
I talked to the R&D team and they agreed that the SPI could be the bottle neck here and they are working on a solution. It may take 1-2 months before we can have a patch out.
For now, our suggestion is to try increasing the packet you can send on each BLE packet (increase DLE and ATT_MTU)
The reason is that each L2CAP fragment is allocated one buffer, and SMP module only has 4 buffers.
Please have a look at the throughput example \nrf\samples\bluetooth\throughput.
Hi, Hung :
Thanks for helping to clarify the issue. we will try to increase the DLE and ATT_MTU.
Please let us know when there is a new patch. Thanks a lot !
Best Regards
Frank
