Possibly, incorrect start address in HEX files in SDK for Mesh

[Geom]

One little example
At the bottom of file nrf5SDKforMeshv310/bin/ospace/examples/dfu/dfu_nrf52840_xxAA_s140_6.1.0.hex

:040000033000BEE922

We can make it more human-readable by utility from intelhex library:

python your-venv-path/bin/hexinfo.py nrf5SDKforMeshv310/bin/ospace/examples/dfu/dfu_nrf52840_xxAA_s140_6.1.0.hex
- file: 'nrf5SDKforMeshv310/bin/ospace/examples/dfu/dfu_nrf52840_xxAA_s140_6.1.0.hex'
  entry: 0x3000BEE9
  data:
  - { first: 0x00026000, last: 0x0003F05B, length: 0x0001905C }

I believe, value 0x3000BEE9 has two errors:

1. First two bytes are printed in reversed order
2. Application start address is not word-aligned

Most probably, correct value is 0x0003BEE8
We can see this in included file nrf5SDKforMeshv310/bin/ospace/examples/dfu/dfu_nrf52840_xxAA_s140_6.1.0.map:3793

 .text          0x0003bee8       0x3c examples/dfu/CMakeFiles/dfu_nrf52840_xxAA_s140_6.1.0.dir/C_/mesh/deps/nRF5_SDK_15.2.0_9412b96/modules/nrfx/mdk/gcc_startup_nrf52840.S.obj
                0x0003bee8                Reset_Handler

This issue (?) is present in more HEX files included in SDK for Mesh

[Geom]

Thanks for your answer
It explained me many

I added a question in Launchpad GNU Arm Embedded Toolchain forum

[Vidar Berg]

Thanks for the update. Hope the question gets answered on Launchpad.