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

[Vidar Berg]

Hi,

The type 03 "Start Segment Address" record seems to be pointing to the reset vector (@0x26000 + 0x4) which holds the address of your reset handler plus the thumb bit, and the thumb bit explains why it's not word-aligned.  But I'm not sure why objcpy is producing the "strange" byte order for this particular record type. It's probably correct but I couldn't find any specification to confirm it. Are you using any tools that use reads this record type, or are you just trying to understand the format? Either way, it will not affect program execution as the entry point is fixed on the ARM architecture. 

[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.