NRF52 Bootloader hanging

[Chris]

Hi,

I've been using these parts for a few years (the 51) and recently did some work getting the boot loader to be joined together with the application into a single burnable file.

My application is working fine with the SD, and previously I had the boot loader working fine as well but for whatever reason it is now hanging in

sd_softdevice_enable

I've checked on two seperate boards and same problem. If I flash the app + SD it works fine. I use a common .h file between them so the crystal reference is the same.

    // Low frequency clock source to be used by the SoftDevice
#define NRF_CLOCK_LFCLKSRC      {.source        = NRF_CLOCK_LF_SRC_XTAL,            \
.rc_ctiv       = 0,                                \
.rc_temp_ctiv  = 0,                                \
.xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM}

I've spent a day on this so far and am stumped.

I've tried the default boot loaders for the PCA10040 (as I have the latest release parts on my custom boards) and they don't hang but they don't advertise either.

My own code is a duplicate of the boot loader but had a little bit of extra stuff like UART output etc etc. So I adjusted the .ld file to make it a bit bigger and also changed the starting offset in the dfu_types.h (plus the check during startup isn't complaining).

But this all worked fine a few months ago (yes, check the change logs I know but nothing showing).

I know not the most obvious. It's not throwing an error (I build with -DDEBUG and put in an error handler to dump the error code).

The SD is the s132_nrf52_2.0.1_softdevice.hex version.

Basically it never returns from sd_softdevice_enable which would imply some Osc issue (i.e.: we set it to expect an external osc which isn't there.. but this exact same setting when I run my application code works fine)... I have two oscillators on the boards..

I am on SDK 11 recently updated so wondering if something there caused me some grief.. but I had done a merge to check on diffs and nothing exciting.

Any clues? Guesses?

[Chris]

Ok, this isn't exactly an answer as on earlier SDKs this didn't cause a problem but now it seems to. And why on earth it then causes an issue far after the following code and during the init of the SD I don't understand either.

But I tracked it down to this

#define BUTTONS_NUMBER 0
#define BUTTON_START   0
#define BUTTON_1       0
#define BUTTON_2       0
#define BUTTON_STOP    0



/**@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(DIAGS_BUTTON,
                             BUTTON_PULL,
                             NRF_GPIO_PIN_SENSE_LOW);
    
}

Yes, I know, why define them if we're not using them. But this is a common file I use across a bunch of boards.

Anyway, it caused all the grief with the problem described above.

Don't init my lack of buttons. All working fine.

No idea why this has now caused a problem but it has... bit of a wild goose chase.

[Hung Bui]

@Chris: You can always reconfigure the bootloader so that you can run it in debug mode and add a breakpoint at the app_error_handler to track back on why it causes an error. Have a look here to know how to configure the bootloader for debugging.