A way to validate the hex file burned into device against the result (hex) of original source code

[Sansei]

Engineerings, We are looking around to find a way to prove that the hex file burned into the device is really the result of the original source code. Is there any idea/way to validate?

How Nrfgo verify the program code burned into the device? I'm asking on program code hex structure.

[Jørn]

The hex files (at least from keil) are written in the intel hex format. The data field of the data records are the instructions stored in flash, and should correspond with the hex file you dump from the chip. At least in theory, I haven't actually tried this myself.

[endnode]

Right, all "HEX" binaries in embedded programming basically are Intel HEX format as per your link. Also all Nordic tools like nRFgo Studio or nrfjprog can dump the chip flash and store it in HEX format. Btw. that's more or less what happens if you use "verify after flash" option in certain programmers...

[Sansei]

Useful link, thanks. I just want to know how/where the program code is stored on the hex file. Is there any schematic/drawings provided by Nordic to show us the location/address of Application Code and Data in the hex file? A way to parse Program Code and Data, so for validating compiled hex against device-hex I can compare the code segments.

[endnode]

That's up to your compiler and linker, nothing to do with the chip vendor;)

[endnode]

To be precise: there are no real "segments", typical FW for nRF5x consist of Soft Device (which is at the bottom of addressing space, see any Soft Device HEX), application FW (starts at address given by SoftDevice version to be able to work togeather) and then optional things like separate bootloader and/or pre-loaded application data blobs.