IOS-nRF-Mesh-Library
IOS-nRF-Mesh-Library copied to clipboard
NordicSemiconductor
Implement DFU feature
As a power user, I want to be able to flash mesh nodes with newer firmwares so that I can easily test, update and verify network operation with the latest firmware versions.
We haven't spec'd this yet, but we are planning to do so this coming week, will keep you updated about the roadmap:)
Not in the coming months. I have to switch to another project for some time.
Okay, when are you moving on? What will be the state of the application?
I'll transition after I'll release the version 2. I'll be also fixing bugs after that. The version 2 is almost ready, there are some more features I want to add, e.g. database migration from version 1.
We understand, but I'm really busy with other things :( And the official spec for mesh dfu isn't even released yet!
Hey @philips77 about the "And the official spec for mesh dfu isn't even released yet!" we also notice that it has being pushed back, originally expected on spring 2020 now its summer 2020... so got me thinking if maybe there is a case about implementing BLE DFU as a temporary solution? I wonder how difficult from the app and firmware would this be? is it temporary solution worth exploring? or the complexity for just few months is not really worth it?
I didn't read the draft, so I don't know how much work would it require. We also don't have it out backlog now.
I see... we checked the current DFU from others like Cypress and Silvair, they don't seem to be a "Mesh" DFU, instead they seem to update 1 device at the time using several (4) proxies as a "queue", my idea was to make something like that as a temporary solution. However this brings few questions, for example all the nodes needs to have proxy enabled, we actually disable most of the proxies, then someone needs to go walking very slowly trough the whole site updating 1 device at the time... all in all this "mesh" BLE DFU doesn't seem a very good idea, but still maybe worth it as a temporary solution until the real Mesh DFU model comes from the SIG?
I would like to ask a few questions about DFU:
-
Is there a DFU plan that supports the same device firmware in the Mesh network?
-
Understand that all current new functions only support NCS SDK, nRF5 SDK no longer updates new functions, only fix bugs, currently we are using firmware written by NCS SDK, chip memory must be 512K or more to support separate DFU, Is there a better way to support DFU for chip devices with 512K or less memory?
Thanks.
Is there a DFU plan that supports the same device firmware in the Mesh network?
I'm afraid I don't understand.
Understand that all current new functions only support NCS SDK, nRF5 SDK no longer updates new functions, only fix bugs, currently we are using firmware written by NCS SDK, chip memory must be 512K or more to support separate DFU, Is there a better way to support DFU for chip devices with 512K or less memory?
Use an external flash memory to download the new firmware, MCUboot which is used for firmware update in NCS SDK can be used with external flash. For more information, please check infocenter or DevZone.
Is there a DFU plan that supports the same device firmware in the Mesh network?
It means that only one device needs to be upgraded, and the Mesh network will automatically upgrade other devices of the same device type. For example, if there are five lights in the same network, one of the devices will be upgraded, and the other four will be upgraded automatically.
Thank you very much, it seems that the only way to increase external storage or use other chip models.
So there will be many ways you may do DFU. The best one from mobile phone's point of view is indeed initiating DFU using mesh protocol, then sending a new firmware using a OOB (Out Of Band, not through mesh proxy service, but something much faster) and confirming with mesh protocol. Then the proxy node (with dfu capabilities) would be responsible for transferring it to all nodes registered during the initialization phase. You send once in 1 minute, and the image distribution takes very long time.
As far as I know, the official specification is still under development. Realistically speaking, I don't see it coming to mobile implementations in 2022.
Thanks‥ unfortunate but good to know
Is there a good example alternative using mesh and DFU over BLE in the meantime or should we just hold off on BLE mesh implementation ?
Le 20 avr. 2022 à 02:27, Aleksander Nowakowski @.***> a écrit :
As far as I know, the official specification is still under development. Realistically speaking, I don't see it coming to mobile implementations in 2022.
— Reply to this email directly, view it on GitHub https://github.com/NordicSemiconductor/IOS-nRF-Mesh-Library/issues/58#issuecomment-1103693829, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPS37U25I2P4A7YKR7JN3TVF7EW5ANCNFSM4FMMW22Q. You are receiving this because you commented.
it has been released: https://www.bluetooth.com/mesh-device-firmware-update/
;-) any hints @philips77 ?
Yes. With 4.0 released the DFU will come in 4.1. I need to switch to Android for a bit to fix some issues here and there and I'll start updating all my mesh nodes like a crazy person. Hopefully by end of this year you'll be able to join me and we will update the world!
On Android DFU will come later. We're rewriting the lib in Kotlin (should make it public as soon as it's "usable enough") and we need to focus on implementing the basics first.
For DFU - yes. For transport of the image we will use SMP protocol and nRF Connect Device Manager library, sending meta-data over mesh. Then the DFU proxy should take over and slowly forward the image to desired nodes. That way we'll get 30 kB/s from the phone instead of 0.01.
For DFU - yes. For transport of the image we will use SMP protocol and nRF Connect Device Manager library, sending meta-data over mesh. Then the DFU proxy should take over and slowly forward the image to desired nodes. That way we'll get 30 kB/s from the phone instead of 0.01.
just to understand your reply better: do we get the mesh dfu (Models like BLOBTransfer, FirmwareDistribution and FirmwareUpdate cli/srv)?
or you refer the off-mesh DFU...
thinking of speed, sure: faster is better :)
I think if the fw is moved to distributor, then the speed is not that relevand (distributor will push updates and network will be updated). It would be nice to see in the Lib the minimum required for the Initiator Role:
- Firmware Distribution Client
- Firmware Update Client
- BLOB Transfer Client then UI/Views can catchup later...
would that fit into our roadmap?
I didn't memorize the whole DFU spec yet, like I did the other parts of mesh.
We will use mesh models for sending metadata, but will not use BLOB transfer to send the image to Distributor. Instead we'll use OOB method - McuManager. However, I'll try to implement the upload in transport agnostic way so users can choose other protocols. And, depending on complexity, perhaps we can add BLOB as well, just for completeness. As I said, this amazing novel is waiting for me.