Compiling nRF51822 bootloader example using GCC

RE: Compiling nRF51822 bootloader example using GCC

Ole Morten — Fri, 28 Mar 2014 10:56:19 GMT

Yes, you'll have to split the file using objcopy, and then write both the main part and the UICR part with JLinkExe. You may have to use objdump to see which sections are in your elf file, and where they're supposed to be located. If you have trouble with this, I suggest you post it separately, as it is really an unrelated problem.

It seems the others are on Windows, on which you can use nrfjprog to program insted of JLinkExe directly. nrfjprog supports programming hex files directly, avoiding the need for bin files completely, and is hence more usable in that regard.

RE: Compiling nRF51822 bootloader example using GCC

Samuele Forconi — Tue, 25 Mar 2014 18:08:29 GMT

Hi, thanks for your answer.

Ok, I've understood the problem related to the 256MB file size, but I still have some doubts.

As I understand, to start the bootloader firmware (that resides at some address in flash around 0x03C800) it is needed that the UICR->BOOTLOADERADDR register is loaded with the bootloader firmware start address. How can I load this address into the UICR->BOOTLOADERADDR? Do I need to split the UICR section of my executable file and load that piece of bin separately, similar as is done for the s110?

In the other thread you suggested, the second solution provided by Nikita seems to be similar to the one I have adopted, but there isn't any reference to big executable size using this method.

Samuele.

RE: Compiling nRF51822 bootloader example using GCC

Ole Morten — Tue, 25 Mar 2014 13:34:53 GMT

I'd recommend you to take a look at this question.

The bootloader hex is set up to write to a UICR register, which is mapped at 0x10001014, in addition to the normal code at around address 0. The difference between those are about 256 MB, so for any format that doesn't allow address jumps, you'll see a 256 MB file with almost all 0s. This is the case for raw binary files, but not for elf files or hex files, which include addressing information.

This is also the reason that the Makefile here, that flash the softdevice, splits the hex into two different binaries before writing it to the chip; one with the main flash contents and one with UICR contents.