This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU for existing BLE-device upgrade to mesh

We have exiting BLE 4.0 device, which should be updated to the mesh. nRF52832

In the DFU for BLE4.0 you could update the booltoader and the softdevice  with one update, with the next update you have to update your application.

If I run the update to the mesh-Booltoader and a new Softdevice, than I have the problem, the mesh booltoader has a restriction, that it can't run a dfu of his own, the booltoader needs an application, which wasn't transfered.

Is there a path for such an upgrade over the air? would you tell me please how to solve this problem?

Parents
  • Hi,

    It is possible to run Mesh DFU on a unit that only has bootloader.

    You must merge the Mesh DFU bootloader and Device page before performing DFU with the new bootloader.

    Check mesh/bootloader/readme.md and tools/dfu/readme.md for more information.

    Ketil

  • Hello Ketil,

    thank You for the information.I am using the PCA 10040 devboards with the nRF52832-Chips on it, and the GCC SDK.

    Now I would like to build the update zip-file with nrfutil. For the first step I take the booltoader which is delivered with the Mesh-SDK 1.0.1, and the softdevice s132_nrf52_5.0.0 here are the both files:

    5050.mesh_bootloader_gccarmemb_nrf52832_xxAA.hex

    3348.s132_nrf52_5.0.0_softdevice.hex

    The command to biuld the update-zip-file looks this like:

    nrfutil dfu genpkg --company-id 0x00000059 --bootloader mesh_bootloader_gccarmemb_nrf52832_xxAA.hex --key-file private.key --sd-req 0x009D --mesh dfu_testID2V6_default.zip
    

    The result gives me an MemoryError:

    Key file was given, setting DFU version to 0.8
    Traceback (most recent call last):
      File "__main__.py", line 360, in <module>
      File "click\core.pyc", line 700, in __call__
      File "click\core.pyc", line 680, in main
      File "click\core.pyc", line 1027, in invoke
      File "click\core.pyc", line 1027, in invoke
      File "click\core.pyc", line 873, in invoke
      File "click\core.pyc", line 508, in invoke
      File "__main__.py", line 276, in genpkg
      File "nordicsemi\dfu\package.pyc", line 212, in generate_package
      File "nordicsemi\dfu\package.pyc", line 365, in normalize_firmware_to_bin
      File "nordicsemi\dfu\nrfhex.pyc", line 65, in __init__
      File "nordicsemi\dfu\nrfhex.pyc", line 76, in _removeuicr
    MemoryError

    the version of the nrfutil is the 0.3.0.0

    Would You like give me a hint how to get the both files togeher in one update-file (the problem regards the booltoader, if i take the bootloader only, the same error is thrown)

    Thanks in advance

  • Hi,

    I am looking into this now and I get the same error messages as you do. My colleague does not see this problem and we suspect there might be  a dependency/version issue. Did you manage to find a solution? 

    Ketil

  • Hello,

    thanks for this information, if Your colleague have a running environment, so I would be very interested in such a working environment. My investigation shows, that there are some issues with the memory error. Another post said the same, and the solution ist to excude the ram init data section. With the call:

    >arm-none-eabi-readelf.exe -S mesh_bootloader_gccarmemb_nrf52832_xxAA.elf

    I will get all the data section from the example booltoader - elf-file. If I exclude the 'core_data',

    >arm-none-eabi-objcopy.exe -O ihex -R .core_data mesh_bootloader_gccarmemb_nrf52832_xxAA.elf test.hex

    so I could make a dfu.zip with this hex file, additionaly I merged this output with the device page:

    mergehex -m test.hex device_page_nrf52832_xxAA_s132_5.0.0_ID1_V1.hex -o test_devpage.hex

    device_page_nrf52832_xxAA_s132_5.0.0_ID1_V1.hex

    test_devpage.hex

    If I flash this file with the correct softdevice in the chip, I could find this device with the characteristics 0xFEE4, I hope this is the mesh-dfu. That looks good.

    But my problem is, that I've got a device in the field with a secure-dfu from non-mesh-system. The creation of a dfu.zip- file works:

    nrfutil pkg generate --key-file private.key --hw-version 52 --sd-req 0x9D --bootloader test_devpage.hex --bootloader-version 2 --softdevice s132_nrf52_5.0.0_softdevice.hex sd_bl_mesh_dfu.zip

    the download is ok, but the device never came up, it hangs. I have made dump of the directly download working device, and the after update not working device, there are many differences in the binary data. Maybe somebody at nordic who knows where is the problem with the differnces between the both images could tell me what I have been doing wrong?

    Here The both dump files:

    dumps.rar

    thanks in advance

  • Hi,

    There seems to be a different device page format for the two versions of secure dfu. Most likely the mesh bootloader crashes as soon as it boots up due to not being able to interpret the data. You will have to modify the bootloader to overwrite the device page with the mesh device page format on first boot.

    Ketil

Reply Children
No Data
Related