Bootloader: file specified not a valid hex file

[Cy]

The example bootloader hex files within SDK 15.3 will load on the development board and seems to provide connection through nRF toolbox on a iphone 7 but will not load on custom hardware. The custom boards are fairly mature and have had good success with other applications. The development has been through the armgcc and therefore utilizes the command line tools. The specific command to program the both the development board and my custom hardware was:   nrfjprog --reset --program sd_s132_bootloader_buttonless_with_setting_page_dfu_secure_ble_debug_without_bonds.hex --family NRF52 --sectoranduicrerase which was suggested from the online SDK 15.3 examples documentation. 

When trying to program custom boards through the development board the command line tools suggest that the hex file is not valid as the data is either in or out of the valid area. Any help would be appreciated.

[Cy]

Edvin,

Well, I get that a lot! Sorry to be confusing. Before an nRF52832 can be a bootloader it needs firmware to tell it to bootload. So, a nRF52832 needs to be programmed with a hex file that has all the instruction to bootload. In my case Im just getting started DFUing with my custom hardware, fairly mature, to bootload applications. Nordic has at least a couple of examples, but within the nRF5_SDK_15.3.0_59ac345/examples/dfu/secure_bootloader/pca100_ble/armgcc folder is a good start to finishing what I am attempting, nothing out of the ordinary.  

These examples have pre-compiled files that are bootloaders and they are specific to Nordic's arm processors, in my case my custom hardware, I have selected the nRF52832, and utilize the command line tools for development on a windows 10 work station. nrfutil, nrfprog, make, gcc and specifically gcc-arm-none-eabi-7-2018 q2-update-win32-sha1.

Programming the custom hardware is done with a development board which also has an nRfF2832 arm processor onboard as well as what I am guessing is an atmel chip to handle communication with the work station over USB. Developing with  the development board is nice, because when I run into unexplained situations I can often rule out hardware due to its performance on the development board compared with custom hardware.

In this situation that is exactly what I have done, I am comparing programming the nRF52832 on the development board programmed by the atmel chip which might be called the segger system to programming the nRF52832 on my custom board. So, the pre-compiled hex files, which is a bootloader, works as expected with nRF52832 onboard the development board with the new nRF connect application on my iphone. 

Now, the problem I have been attempting to describe is that I have custom hardware with a nRF52832, fairly mature, will not program that same pre-compiled DFU example through the development system I have been describing. The command line tools complain when I try to program the same pre-compiled file that it is not valid hex file and that it may have instruction outside the chips memory space, like a linking issue, wrong address inside the linker telling the segger system to load DFU firmware outside of the designated bootloader memory,0x00078000 - 0x0007E000 24kB in size, but this same hex file works on the development board nRF52832.

In my limited time developing with Nordic I have not had to monkey with liker files, and again the same pre-compiled hex file which is a bootloader or DFU works on the development board but not the custom hardware.

I have not attempted to create a zip file for an application because I have not been able to program the pre-compiled hex file which is the bootloader or DFU onto the custom hardware.

[Edvin]

Ok. I understand. Thank you for explaining.

So the issue is that you are not able to program the custom board with the hex file, and it is not related to the DFU process.

What chip is on your custom board? May it be the QFAB, which has less RAM and Flash than the nRF52832 QFAA which is on the DK? You can see the different versions here.

Do you get the same issue if you try to flash another example, such as the ble_app_blinky example, or is it only on the bootloader .hex file?

[Cy]

Edvin,

Yes, I have QFABs mixed in with QFAAs and the QFABs will not program, but the QFAAs will. Thank you!