Hello.
We are looking for a viable solution on how to transfer a firmware over the BLE OTA from Particle Tracker (Gateway) to nRF52840 devkit (Client), very preferably in nRF’s native DFU OTA protocols. It occurred to us, there is little to no reference about this topic.
My guess is that this will be difficult for a number of reasons. One is finding enough free space on the Tracker to store the coprocessor firmware image.
While the Tracker is also an nRF52, and the nRF52 SDK is mostly available to user firmware, none of the additional features like BLE DFU are present. It may be possible to add those in manually.
However, the other problem you will run into is that the Tracker also uses BLE for its Particle Device OS BLE features. It’s highly likely that you will run into issues where the two features conflict with each other. You might be able to turn the Device OS features off, which may help.
I also think you’ll run into a problem with handling BLE interrupts from user code.
A less fragile but more difficult solution would be to reimplement the nRF BLE DFU protocol on top of the Particle BLE API. This is safe and would almost certainly work, but would require some effort because you’d have the reimplement the whole thing because the nRF SDK BLE and Particle Device OS BLE APIs are not at all the same.
It seems we are leaning towards the last suggestion about implementing the whole thing. Not much of a choice, except we are not sure where to start, since nRF’s BLE OTA working principles beyond the push of a button are not that obvious. Generally the Tracker product suits us well, except that we are struggling with relaying OTA to our peripheral devices. Are there any known libraries like “fwu”? https://blog.classycode.com/updating-the-firmware-on-an-nrf52-from-another-microcontroller-b513080dc0cd . Except that the one we are looking for might work via BLE (instead of UART) with all the services and attributes related to it. Currently our team is on a fork of decisions, choice of which is determined by the estimated efforts to be put in a new API development. Hence we are humbly asking, how long (in manhours), might it take for one to develop the aforementioned suggestion of a new API? TLDR; we are cannot move on to other steps without knowing what we are about to deal with.
I only looked at it briefly, but that looks like the best option, and seems like it would be feasible.
The fwu library looks to be well-implemented and does not rely itself on the nRF52 transport mechanisms. It’s just a big finite state machine that implements the nRF52 DFU protocol, so that’s good. It should be an easy port.
Since you want to use BLE instead of serial, I’d use the nRF BLE UART example. There are examples that work on Particle Device OS (UART central) and versions for nRF52 native in the SDK, so that’s good.
The only thing I’m not positive is if enough of the stack is running when nRF52 DFU is being run to do it over BLE. The BLE stack is in soft device, and there’s a lot of stuff that needs to be started to get to that point. That’s a generic nRF52 issue on your coprocessor, so it should be easy enough to figure out.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.