Hello. I am at the point in my project (using sdk v12) where I need to get DFU implemented.
In my case, DFU must occur through an alternative transport that is none of the 'usual suspects' of BLE, serial, etc.
Having struggled to get DFU implemented at all in the past, I am extremely impressed by how you've generalized the DFU transport mechanism. I don't understand it all yet, but the modularity is really slick.
I'm also incredibly impressed with the new secure code signing mechanisms. Such an improvement, and really the right thing to do for the industry.
That said, the actual DFU mechanisms are still pretty much a black box to me at this point, and given the complexity I think it's best that I treat it like a black box as much as I can - focusing on transport and not on the logic performed to actually unpack the image and do the DFU.
As a starting point, I've got DFU in my project implemented to the point where it (now, finally) works flawlessly with BLE dfu from my iphone.
For my custom DFU, the state is that:
-
I've got an external storage device attached to the UART that is addressable with AT commands
-
The only AT command relevant here is that I can ask the device to stream the file contents into the nrf52 over the uart. The file contents is streamed inward in variable sized chunks, from beginning-of-file to end-of-file. It is sequential fetch only; no random seek allowed.
-
Before I ever get into the bootloader to begin the DFU, the ZIP file for the image has been downloaded into that device. The bootloader will go into buttonless DFU mode if and only if the AT commands indicate that the file is present on that device.
And so, ideally, my task will be to "simply" (!) enhance the bootloader to have a custom transport that does as little logically as possible other than to read and feed the file into someone else's already-debugged logic to process it and to "do what the phone does", ultimately generating and calling nrf_dfu_req_handler_on_req's to process what's in the zip file and do the dfu.
Given that I am about to embark upon the process of reverse engineering the IOS DFU library to see what the heck it's doing and how it works, it occurs to me that I should just stop and ask you:
Do you have a different alternate transport written yet (such as UART), even if pre-release, that I can use as a starting point rather than to do this extremely complicated reverse engineering?
Your assistance would be greatly appreciated because this task is looking to be a bit daunting at this point.
Thanks much.
