nRF52 Bootloader acting differently on different boards

RE: nRF52 Bootloader acting differently on different boards

bjorn-spockeli — Thu, 04 May 2017 14:28:02 GMT

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.

RE: nRF52 Bootloader acting differently on different boards

bjorn-spockeli — Thu, 04 May 2017 14:27:52 GMT

I am afraid that I do not know how to use RedBearLabs Arduino Library to set the LFCLKSRC to the internal RC oscillator. In our bootloader example from SDK v11.0.0 you change it by modify the NRF_CLOCK_LFCLKSRC in the pca10040.h or custom_board.h to the following

#define NRF_CLOCK_LFCLKSRC      {.source        = NRF_CLOCK_LF_SRC_RC,            \  
                                     .rc_ctiv       = 16,                             \   
                                     .rc_temp_ctiv  = 2,                              \
                                     .xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_250_P

RE: nRF52 Bootloader acting differently on different boards

Steve — Thu, 04 May 2017 14:01:00 GMT

Thanks Bjorn,

The custom board does not have a 32KHz crystal. Is it possible for me to use the Arduino IDE that is used with the BLE Nano in order to set the board to use the internal RC?

I guess it needs to be set in the bootloader, or can I set this in my application?

Regarding merging hex files, the only bootloader than I have been able to successfully merge with my application Hex that the Arduino IDE produces is the 'SoftdeviceS132_2.0_SDK11_Bootloader_20161221.hex' As I believe the address locations that are set in the Hex files need to match up.

I also don't fully understand why on the nRF52DK the bootloader gets stuck in OTA advertising mode, and does not run the application. Is there a trigger that causes this?

Cheers

RE: nRF52 Bootloader acting differently on different boards

bjorn-spockeli — Thu, 04 May 2017 11:31:30 GMT

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.