Custom nRF522832 secure BLE DFU bootloader from example

[Bilal Bouguerra]

Hi all,

I am currently trying to develop my own Secure BLE DFU bootloader from the example provided in the SDK 12.3.0. I don't work on the DK, I have my own board with a nRF522832.

The example works fine but when I try to remove one of these lines in the main, the application transferred via DFU is no longer runned by the bootloader. I don't understand because these lines don't seem to be in relation with BLE or DFU functions:

/**@brief Function for initialization of LEDs.
 */
static void leds_init(void)
{
    bsp_board_leds_init();
    bsp_board_led_on(BSP_BOARD_LED_2);
}


/**@brief Function for initializing the button module.
 */
static void buttons_init(void)
{
  nrf_gpio_cfg_sense_input(BOOTLOADER_BUTTON, BUTTON_PULL, NRF_GPIO_PIN_SENSE_LOW);
	//nrf_gpio_cfg_sense_input(30, BUTTON_PULL, NRF_GPIO_PIN_SENSE_LOW);
}

[...]

leds_init();
buttons_init();

I don't need these lines as I have my own pin config, can I get rid of them ?

I have the same problem if I keep these lines but just change the pin number from BOOTLOADER_BUTTON to 30 (which is a button in my pin config).

Thanks

[Bjørn Kvaale]

Have you tried running the debug bootloader & debug exactly where in the process this error occurs? The LEDs are related to advertising on the DK, as the LEDs are used to indicate if the bootloader is advertising or is in bootloader mode. In addition, holding in button 4 on the DK during startup will lead to the board entering bootloader mode (see link). It might be that you have not yet updated this functionality in the bootloader code.

[Bilal Bouguerra]

Thank you for your answer,

If I run the debug version of the bootloader, how do I debug it ?

So if I understand, if I want to remove the leds_init and buttons_init functions I have to remove other things in the libs/drivers code ?

[Bjørn Kvaale]

You can follow the infocenter documentation to test the bootloader & use a segger rtt viewer for example to see all of the NRF_LOG_INFO() prints inside the bootloader example. Make sure NRF_LOG_ENABLED 1 & NRF_LOG_BACKEND_SERIAL_USES_RTT 1 inside sdk_config.h (they should already be set correctly I believe). Then, you could add more NRF_LOG_INFO() prints to find out where the code is stalling.

Also, check to make sure the optimization level is set to Level 0 so that you get enough debug information out. In Keil, you can do this by clicking on the Project tab -> Options for Target -> C/C++ tab -> Optimization: field (this should be set to Level 3 default). The bootloader will increase in size, but it should still be possible to program the bootloader without having to change the ROM settings.

In addition, I believe it should be possible to debug inside the IDE you are using too if you prefer that.

Regarding removing other code, this is just my guess. That is why I think it is a good idea to debug the bootloader to see where the error occurs.

 Update: I had previously said you want optimization level 3, but this was wrong. I meant optimization level 0 to get more debug information.