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

Eclipse compiled hex file smaller than included hex

I've managed to overcome all the quirks in setting up Eclipse/gcc development with the nRF52 PDK (PCA10056), and I can build the sample projects just fine. Here's my issue: If I compile and load the "blinky" example project, it runs perfectly. If I try to do the same with ble_app_uart, it compiles just fine, but when I load the resulting hex file, it doesn't work--the nRF Connect app can't see it, there's no blinking LED on the PDK, etc.

I also noticed that the .hex file that results from the build is only 84kB, whereas the pre-compiled .hex in the SDK is 421kB. I suspect there's something wrong with the build, so when it loaded onto the chip, it doesn't run correctly, but I have no idea where to start looking for issues--there are no problems in the build process.

I programmed the s140 SoftDevice to the target earlier, and have verified (using nRFGo Studio) that it's still there.

Where should I look in order to figure out what I'm doing wrong?

  • Hi,

    First of all the HEX files supplied with SDK are already merged with Soft Device (where applicable), you can easily verify that by comparing content with any tool like Kdiff3. Then even if you strip SD part and compare just "APP" you will most probably arrive to different content and size because Nordic compile by default with Keil or IAR and you are using GCC. But that should not be a big problem (and if you like to start with 100% binary compatible output - as I do - you will need to use different compilation chain - which I don't like as well, GCC is great).

    The fact that your FW is not working is probably caused by some linking/include error, e.g. not setting RAM and FLASH boundaries properly in LD script or so. If you show us more from GCC output when you build the thing we might give you more hints.

    Cheers Jan

  • Do you mean the output in Eclipse's Console when I build the project, or some other sort of ourput?

  • Yes, console output. Alternatively build it with UART debug print outs, run some serial terminal (e.g. PuTTY) nd verify if FW boots and if so where it hangs.

  • Here's the console output: uart_compile_log

    I added a bunch of statements like this after various stages of the initialization in main()

    printf("\r\nUART Start!\r\n");
    

    When I copied the .hex file to the JLINK drive, rather than the file disappearing like it often does, the .hex file stays there. I also hooked up a serial adapter to the PDK, and saw nothing when I copied the file over. When I do it with the pre-compiled version, I see the "UART Start" appear, so I know it's all hooked up correctly.

  • OK. Compilation looks good, I would just stick (for the beginning) to the compilation chain Nordic recommends in nRF5 SDK V13.0.0 release notes: GCC ARM Embedded 4.9 2015q3. When it comes to verifying on PCA10058 bard:

    • You normally don't need to hook any additional cable like "Serial to USB" adapter, it should go through SEGGER J-Link OB serial port emulation (companion chip on the board which handles USB connection to PC host). All examples are using header files which should automatically use proper PINs to make this work. On PC side you should see J-Link COM port.
    • I never use this "drug and drop" programming method because I simply cannot control the process;) Setting up proper programming routine in nrfjprog (part of NRFTOOLS bundle) or nRFgo Studio (or anything else) should help. Then you can be sure that nRF52 chip is erased and programmed with both SD + APP HEX files.
Related