• State Suggested Answer
  • +1 person also asked this people also asked this
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 68 subscribers
  • Views 3256 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 218915
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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)?

  • 0 in reply to mrono

    To test it I just used nRF Connect. I flashed the DFU buttonless app and DFU service from SDK 15.2 on nRF25832 DK, connected, jumped to bootloader, reconnected to a new device (address has changed), enabled notifications on Secure DFU Control Point and sent 0x07, ... to this characteristic.

    As a result I received 0x60-07-01. The expected value should be 0x60-07-01-BB-AA where AA-BB is the MTU (BB-AA as Little Endian is used).

    The SDK team says that UART and USB DFU samples report those values correctly, only the BLE part does not. You need to modify both the preparation of the request in on_write() and the serialization of the response in ble_dfu_req_handler_callback(). See nrf_dfu_serial.c for reference. I guess @Mmtrinh may help you. After you implement the changes I mentioned above, yoou could request the HW version from the device before starting DFU. DFU Library will not use those features as it assumes that the firmware you try to send is correct and will in worst case handle validation error.

    I forwarded the issue you mention to the SDK team. The response I got:

    It makes sense. We probably won't change it though, but they are free to add it themselves, or to consolidate the HW version with some value reported by this command.

  • 0 in reply to Aleksander Nowakowski

    Thank you for the instructions. It is so simple I should have figured that out. But I was too focused on trying to use the DFU library for this...

    I could implement those changes myself but I don't think I will. I fear that I might make them slightly different than the official fix I presume will be done for some future SDK. And slight compatibility issues are the worst kind. Obvious ones are much easier to work with. I have a solution that works (add the values to the advertising packet), so I'll keep using that and re-evaluate this issue if there is an SDK that has those fixes.

  • 0 in reply to Aleksander Nowakowski

    There is indeed a bug in the BLE transport code in the library, most of the codes that are correctly handled in \Nordic152\components\libraries\bootloader\serial_dfu\nrf_dfu_serial.c are not handled at all under \Nordic152\components\libraries\bootloader\ble_dfu\nrf_dfu_ble.c , making the bootloader library buggy and incomplete at this point Disappointed

    What is even worse is that any bootloader already programmed in any device will need first to be updated to support the correct and full specification for the version of protocol that the library was supposed to implement Disappointed Disappointed

  • 0 in reply to Catalin

    Hi, the issue with BLE bootloader reporting 0x60-[Command ID]-01 (success) instead of a value or NOT SUPPORTED has been fixed in SDK 15.3.

Related