The GCC-made DFU bootloader doesn't work in version 15.3 project.

[Boris]

Hi, everyone,

We are developing project on nRF52832 by using the newest 15.3 version (nRF5_SDK_15.3.0_59ac345). The project is built from bootloader and main application. The bootloader is created from example that exists in folder “E:\Nordic\nRF5_SDK_15.3.0_59ac345\examples\dfu\secure_bootloader\pca10040_ble”. The development is prepaired in Visual Studio Visual GDB environment that uses the GCC compiler. Due to this version we migrate the example taken from “E:\Nordic\nRF5_SDK_15.3.0_59ac345\examples\dfu\secure_bootloader\pca10040_ble\arm5_no_packs” folder. Similarly as in one of the previous versions (version nRF5_SDK_15.0.0_a53641a), in the project we replace “E:\Nordic\nRF5_SDK_15.3.0_59ac345\external\micro-ecc\nrf52hf_keil\armgcc\ micro_ecc_lib_nrf52.lib” file to “E:\Nordic\nRF5_SDK_15.3.0_59ac345\external\micro-ecc\nrf52hf_armgcc\armgcc\ micro_ecc_lib_nrf52.a”. In difference to previous 15.0 version in this project exists the “E:\Nordic\nRF5_SDK_15.3.0_59ac345\external\nrf_oberon\lib\cortex-m4\hard-float\short-wchar\oberon_2.0.7.lib” file. We replace it with the “E:\Nordic\nRF5_SDK_15.3.0_59ac345\external\nrf_oberon\lib\cortex-m4\hard-float\short-wchar\liboberon_2.0.7.a”.

But although the project is built correctly without any error, the flashed program to the module doesn’t start working.  

We tried to look to the linkerscript. The difference to the previous versions was in the next two lines:

“uicr_bootloader_start_address (r) : ORIGIN = 0x00000FF8, LENGTH = 0x4 ”         and

“uicr_mbr_params_page (r) : ORIGIN = 0x00000FFC, LENGTH = 0x4”              in 15.3 versions

In comparison to next two lines

“uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4” and

“uicr_mbr_params_page (r) : ORIGIN = 0x10001018, LENGTH = 0x4” in 15.0 version.

The origin definitions “0x00000FF8” and “0x00000FFC” caused to compiler overwrite the cluster with the softdevice because these to addresses were written to one of the soft-dev clusters. Due to this reason we tried to burn the project by merging it with soft-dev-.hex file by the “nRF Connect \ Programmer” program. The Keil-made-project worked in this case perfectly, while the GDB_GCC-made-project didn’t work at all.

We tried to redefine the “0x00000FF8” and “0x00000FFC” addresses to the “0x10001014” and “0x10001018” ones accordingly like in 15.0 version. But although the BLE-Soft-Device wasn’t overwritten at all the project didn’t want to start working anyway.

What wrong was done or what wasn’t done correctly in the migration?

Best Regards

Boris Fridman

 

[Einar Thorsrud]

Hi,

I do not see anything wrong here. 

The address of the MBR params page and bootloader start address must be stored in 0x00000FF8 and 0x00000FFC as is the case in the example bootloader, as this is the location that is checked by the MBR after reset. This was introduced in SDK 15.3. The downside of doing it like this is that you must make sure that you delete and program the .hex filed in correct order (for instance, you cannot the first program the bootloader then program the SoftDevice with a sector erase, as that will delete the data at the end of the MBR page which is part of the bootloader .hex).

[Boris]

Hi, Einar Thorsrud,

We tried to troubleshoot the project, but there were some strange things:

1. We tried to burn the bootloader by “nrfjprog” utility without “-- secotrerase“ parameter but the utility gave error. Even more in help was written that one of erase parameter must be selected when the hex file is burned. And with “--chiperase” or “-- secotrerase“ parameter the previously burnt hex file will be erased. We tried to burn by “nrfjprog” both “.hex” files (softdevice and bootloader) together by one command, but this command wasn’t be accepted too. So both “.hex” files could be burnt only by “nRF connect\Programmer” program. How is it possible to burn softdevice and bootloader hex files by nrfjprog utility together without merging them?
2. You answered that the address of the MBR params page and bootloader start address mustbe stored in 0x00000FF8 and 0x00000FFC as is the case in the example bootloader, as this is the location that is checked by the MBR after reset. And that this was introduced in SDK 15.3. But the definitions of “uicr_mbr_params_page” and “uicr_bootloader_start_address” existed in linkerscripts of previous SDK versions too although they pointed to the other addresses at all. Were they implemented in previous versions too or there they were defined only?
3. We tried to exclude from project oberon files at all without adding there neither “liboberon_2.0.7.a “ nor “oberon_2.0.7.lib” at all. And the project could be compiled successfully. In addition the file "liboberon_2.0.7.a" exists not only in “E:\Nordic\nRF5_SDK_15.3.0_59ac345\external\nrf_oberon\lib\cortex-m4\hard-float” path, but also in “E:\Nordic\nRF5_SDK_15.3.0_59ac345\external\nrf_oberon\lib\cortex-m4\hard-float\short-wchar” too. Are these file same or they have any difference?
4. We tried to compile the project with

“micro-ecc\nrf52hf_armgcc\armgcc\micro_ecc_lib_nrf52.a”,

“micro-ecc\nrf52hf_iar\armgcc\micro_ecc_lib_nrf52.a” and with

“micro-ecc\nrf52hf_keil\armgcc\micro_ecc_lib_nrf52.lib” files. In difference to the previous versions the project could be compiled with each one from them while in previous versions it could be compiled with “micro-ecc\nrf52hf_armgcc\armgcc\micro_ecc_lib_nrf52.a” file only. But in any case also the project is compiled with each one of these files (separately) the bootloader cannot work with anyone of them.

 

Thanks forward for paying attentions

 

Best Regards

Boris Fridman

[Einar Thorsrud]

Hi Boris,

Boris said:

How is it possible to burn softdevice and bootloader hex files by nrfjprog utility together without merging them?

The simplest is to merge them. Alternatively, you need to make sure that you first erase the flash pages containing both the MBR (SoftDevice) and the bootloader. The simplest is to just do a full chip erase before you program them. You can do it in this order:

1. Full chip erase ("nrfjprog -e")
2. Program SoftDevice .hex file (which includes the MBR)
3. Program the bootloader

Boris said:

You answered that the address of the MBR params page and bootloader start address mustbe stored in 0x00000FF8 and 0x00000FFC as is the case in the example bootloader, as this is the location that is checked by the MBR after reset. And that this was introduced in SDK 15.3. But the definitions of “uicr_mbr_params_page” and “uicr_bootloader_start_address” existed in linkerscripts of previous SDK versions too although they pointed to the other addresses at all. Were they implemented in previous versions too or there they were defined only?

The definitions existed in earlier versions as well, but then they pointed to the UICR. However, it is not possible to write protect the UICR from the application, and therefore it was moved to the end of the MBR params page so increase security if a user wants to implement something similar to secure boot. So the concept is old, it is just that the location checked by the MBR in SoftDevice version >= 6.0.0 (used in SDK version >= 15.0.0) has changed.

Boris said:

We tried to exclude from project oberon files at all without adding there neither “liboberon_2.0.7.a “ nor “oberon_2.0.7.lib” at all.

You only need the backend you configure for ECDSA in sdk_config.h. If you don't want the Oberon backend, you don't need any. Regarding the various versions they are for different toolchains (see nrf_oberon backend).

Br,

Einar