Segger Embedded Studio outputs different then expected .hex file

RE: Segger Embedded Studio outputs different then expected .hex file

Eyar Gilad — Wed, 22 Nov 2017 11:53:53 GMT

I verified the start addresses with those in Keil and in ble_app_thingy_gcc_nrf52.ld file located in thingy_sdk_v2.1.0\project\pca20020_s132\armgcc , They match.

RE: Segger Embedded Studio outputs different then expected .hex file

endnode — Wed, 22 Nov 2017 07:35:15 GMT

The start address looks wrong and there might be some other reasons. When I quickly looked on the blog post about how to set-up the project in SES it's fairly long (and also mentions how to set ROM and RAM start addresses). Are you sure that you haven't done any mistake and that all is aligned with Soft Device version you use?

RE: Segger Embedded Studio outputs different then expected .hex file

Eyar Gilad — Wed, 22 Nov 2017 06:29:20 GMT

Thanks for the response. I get what you say and indeed both the Keil .hex output and the Cygwin make output are different and both of them program and run fine. SES output however does program but does not run, at least not the way it should. flash_placement.xml and MemoryMap.xml are my best guesses to be the source of the problem since everything compiles fine. If you think I should look else where please tell me.

RE: Segger Embedded Studio outputs different then expected .hex file

endnode — Mon, 20 Nov 2017 16:12:32 GMT

Btw. note that this is about compilation chain and not IDE, so e.g. Eclipse can use several build-chains and thus generate different binaries depending on how you install and configure it. Other IDEs like Keil MDK or IAR Workbench are bundles of both graphical interface and compilation/debugging tool-chain.

RE: Segger Embedded Studio outputs different then expected .hex file

endnode — Mon, 20 Nov 2017 16:10:21 GMT

Welcome to the world of ANSI C compilers and linkers;) Yes, different build chain means different output, this is expected. Nordic uses one toolchain to provide reference binaries (usually HEX files) and it used to be IAR, not sure if it is still true with nRF5 SDK v14.x and Thingy. But it should be written in release notes. This doesn't mean that any of these HEX files won't work! If you have correct source code and correctly configured compilation chain they should be both fine. It's just different level of optimizations and other tricks which make binaries different, some tools are more expensive and promise smaller code size, RAM footprint or faster execution, some are simply open source and free but they can be pretty competitive nowadays. It's up to you what are your priorities and budget.