nRF52 Bootloader acting differently on different boards

[Steve]

Hi All,

I have developed an application on the RedBear BLE Nano2, and am trying to port it accross to a custom nRF52 board.

The Hex that the Arduino IDE outputs does not contain the soft device, so I have run MergeHex to combine the SoftDevice/Bootloader that the application hex is intended to work with.

The bootloader is: SoftdeviceS132_2.0_SDK11_Bootloader_20161221.hex

The merge works correctly, and if I drag and drop the resultant hex file over the DapLink to the BLE Nano, everything works.

When I use the DapLink to program the custom board, nothing seems to run.

I also tried putting the same hex file on an nRF52K, and this ends up getting locked in the bootloader mode.Constantly advertising dfuTarg.

I have written a lot of code using the RedBear Libraries, which is happily working on the BLE Nano2, and I would love to get this working on my custom board. Any advice about why the bootloader/softdevice may be going screwy would be appreciated, or advice on how to merge my application hex with a different SoftDevice file would also be helpful.

Pleae can someone explain the cause of the different behaviours I am seeing, and how I overcome it?

Cheers.

[bjorn-spockeli]

Hi Steve,

Does your custom board have an external 32kHz crystal on it? If not, then you will have to set the Low Frequency Clock Source to use the internal RC oscillator. It looks like the BLE Nano2 has it and I know that the nRF52 DK has it, so that might be the reason why your code is not running on the custom board.

If you want to flash a combined SoftDevice, Bootloader and Application hex file created with mergehex, where the device jumps to the application without having to perform a OTA update, you have to set the BANK_VALID_APP flag in bootloader_settings.c, i.e. change the line

uint8_t  m_boot_settings[CODE_PAGE_SIZE]    __attribute__((at(BOOTLOADER_SETTINGS_ADDRESS))) __attribute__((used));   

to the following

uint8_t  m_boot_settings[CODE_PAGE_SIZE]    __attribute__((at(BOOTLOADER_SETTINGS_ADDRESS))) __attribute__((used)) = {BANK_VALID_APP};

Alternatively you can merge the bootloader hex with this hex file to set the BANK_VALID_APP flag.

[bjorn-spockeli]

Yes, you have to make sure that the application and bootloader hex files does not overlap, otherwise you will get an error when you try to merge them.

The bootloader will look for the BANK_VALID_APP flag on the bootloader settings flash page and start the application if it is set to true, i.e. 0x01. The flag is by default is set to false. Thus, when you flash the BL, APP and SD, the flag will still be set to false and the the bootloader will remain in bootloader mode until you perform a application DFU, which upon completion will set the flag to true.