DFU example for NRF_DFU_OP_FIRMWARE_VERSION

[Catalin]

Is there any code example for Android or iOS on how to build / send a DFU request for NRF_DFU_OP_FIRMWARE_VERSION and then how to interpret the response that comes back?

Does it not make sense for the DFU module from inside the nRF Toolbox to also have a way to send this request to a device in DFU mode for instance to check the existing values that are programmed in the device? (and then show a popup to the user for instance to let him know if he needs to update things)?

[Mttrinh]

Hi,

We don't have any code for that. It's up to the application's implementation to know the version, a suggestion is to have a sw version and hw version string in the proper charecteristic.

[mrono]

I really think Nordic should provide at least some support for these DFU requests.

Having the application report the versions is fine as long as the application is working properly. But consider failure scenarios. What if I make a huge mistake and release a buggy application that makes the characteristics inaccessible? The bootloader can still be launched, but how does the iOS/Android DFU library now know what hardware it is talking to? (I have one phone app for several HW variants).

I am considering adding the HW version as manufacturer specific data to the advertising packets sent by the bootloader. But it would be simpler to just ask for the information since the commands seem to be already defined.

[Aleksander Nowakowski]

Hi @Catalin, @mrono,

Both Legacy (since SDK 7.1) and Secure DFU provide a security check to prevent wrong firmware to be flashed on your device. In the init packet there is hardware identifier. IDs of required softdevice(s).

Secure DFU and late Legacy DFU (optinally) prevent also from flashing modified fw by checking the hash and signature (although Legacy DFU does it incorrectly and device still can be bricked, even having a valid fw file).

The following requests:

NRF_DFU_OP_MTU_GET              = 0x07,     //!< Retrieve MTU size.
NRF_DFU_OP_OBJECT_WRITE         = 0x08,     //!< Write selected object.
NRF_DFU_OP_PING                 = 0x09,     //!< Ping.
NRF_DFU_OP_HARDWARE_VERSION     = 0x0A,     //!< Retrieve hardware version.
NRF_DFU_OP_FIRMWARE_VERSION     = 0x0B,     //!< Retrieve firmware version.
NRF_DFU_OP_ABORT                = 0x0C

were added to the DFU for the sake of the new nRF52840 Dongle, which uses DFU to flash firmware. On BLE such requests should either return the requested value, or return NOT SUPPORTED status code.

However, as I tested it out, the bootloader replies with 0x60-[Command ID]-01 (success), but the value is empty. According to me it's a bug and I reported it to the SDK team. I don't know which way they decide to go.

[mrono]

Aleksander Nowakowski said:

However, as I tested it out

So how did you do that? The original question by Catalin, as well as my followup question was precisely on how to send those requests and how to interpret the response. If you could provide some kind of example on how to issue those requests using the iOS/Android DFU libraries then I could probably work out the rest with our iOS contractor.

If the bootloader currently doesn't return the requested values then issuing these requests is pointless. I believe could fix this in the bootloader myself, but that creates another compatibility challenge if an official fix is later done. I have already added the HW version and bootloader version as manufacturer specific data to the advertising packet sent by the bootloader, so I have a solution for the time being.

Since you have reported this to the SDK team, I have an additional related suggestion: According to the DFU protocol spec the response to the NRF_DFU_HARDWARE_VERSION request contains info on the processor variant and memory size, but not the hardware version checked during DFU. Please add this info to the response. Or if the HW version is available somewhere else please tell me where and how.

[mrono]

Aleksander Nowakowski said:

Both Legacy (since SDK 7.1) and Secure DFU provide a security check to prevent wrong firmware to be flashed on your device. In the init packet there is hardware identifier.

So just to summarize what I'm trying to achieve here:

I have a single iOS/Android app that is supposed to update the firmware of N different hardware variants. Assume that the existing firmware is non-functional, and I can only communicate with the bootloader. How can I tell which of the N DFU zip packages I should send to the device? Yes, wrong ones will be rejected but do I really need to try to send all of them until one is accepted? I'd like to ask the bootloader this info.