Hi,nordic team，
im use nrf52840 develop my product with sdk ncs 2.6.the speed of desktop dfu is so slow,and the speed of configurator channel is also slow.i want to transfer my data by cdc .if there is some eexample to show how should i to do?or som document?
Hi,
Can you elaborate a bit more about the issue? Is the problem that BLE transport is slow and therefore you want a different transport or something else? Specificially what do you use and want to use DFU CDC for Note that the nRF Dekstop application also support DFU in form of serial recovery. See nRF Desktop: Bootloader and Device Firmware Update.
PS: If the issue is with Bluetooth performance, you may want to look at CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP which adjusts BLE buffers etc to incrase BLE throughput.
PSS: File transfer over CDC in nRF Dekstop is deliberately slow but it can be optimized. I will look into how.
Hi,
We have looked at this and have some more to share. Our assumption is that you want quicker data exchange (including update image upload) over the nRF Desktop configuration channel. And we assume you relies on our HID configurator script as host tool. Plase let me know if that is not the case.
Generally the configuration channel design focuses on mitigating negative impact on HID device's performance (because of that the update image is transfered slowly, in small chunks). DFU speed was not considered a priority here because DFU image transfer was meant to happen in the background and be nearly unnoticeable for the end-user. After the complete transfer a device reboot can be triggered to let bootloader start using the newly uploaded image. Also, the configuration channel can be used for HID devices connected either over USB, BLE or even through nRF Desktop dongle (config channel relies on HID feature reprots for DFU image transfer).
If you rely on our hid_configurator script, you could try to shorten poll interval on the host computer side by locally modifying parameters in NrfHidDevice.py file (it should make DFU noticeably faseter, but it could have negative impact on HID device's performance). The following parameters could be updated:
POLL_INTERVAL_DEFAULT = 0.02 POLL_RETRY_COUNT = 200
The poll interval (20 ms by default) could be set e.g. to 0.002 (2 ms). Then poll retry count would need to be increased to prevent failures too (2000
should work fine with the new poll inteval).
Thank you for your reply，
Firstly, upgrading through the hid config channel is indeed too slow for us, but if we use CDC to upgrade, there may be issues with the PC driver environment on the client side, and some customers may encounter installation failures of Nordic CDC drivers.
Secondly, we have a large amount of private data transmission, such as RGB equivalent; If the communication ability of the hid config channel is really not fast, we can only find a way to improve the speed through CDC.
I will try to modify the default configuration to see the upgrade effect.
Hi,
Please let me know when you have tested the configuration canges.
PS: May I ask why speed is an issue? Our assumption was that as DFU is done in the background, speed would not be an important factor.
Yes, I tested it and after modifying the macro configuration, upgrading the firmware takes about 3 minutes. Because our firmware upgrade is issued to customers, not downloaded from network access servers before upgrading, users will have at least two perceptions when upgrading:
1. Use the upper computer to select the firmware and start upgrading;
2. After the upgrade is completed, a prompt will appear asking the customer if they want to reset and update to the new program;
We have many RGB lights for users to edit, and one light effect can support up to several hundred frames per second. Therefore, the amount of data here is huge, and the slow speed brings a bad experience
