Advertising after DFU

[Ken A]

My application implements a beacon with services, and a buttonless BLE bootloader.

The application can start the bootloader in two ways.

The first method is executed locally.

#define BOOTLOADER_DFU_START 0xB1
sd_power_gpregret_set(0, BOOTLOADER_DFU_START);
NVIC_SystemReset();

For the second method, a remote device starts the bootloader using the buttonless DFU service.

After the update is complete, the bootloader jumps to the updated application.

If the application is updated with the first method, the beacon is advertised correctly.

If the application is updated with the second method, the beacon stop stops advertising until I perform a system reset or power cycle on the board.

How can I make advertising work correctly without forcing a device reset?

[Edvin]

Have you tried to debug the issue? After the application is updated using the second method, is the application started at all, or is it stuck in the bootloader?

If you enable logging, do you see any logging from the application? If you try to use the pca10056_s140_ble_debug bootloader project instead of the pca10056_s140_ble project, does the bootloader indicate that the application should start, or is it stuck somewhere in the bootloader? You can monitor the log from the bootloader if you use the ..._debug project.

Best regards,

Edvin

[Ken A]

In both cases, after the DFU is complete, the application runs normally (except for not advertising in the second method).

[Edvin]

Ken A said:

the application runs normally (except for not advertising in the second method).

 So it doesn't run normally, then.

Why is it not advertising? Does ble_advertising_start return NRF_SUCCESS?

[Ken A]

ble_advertising_start returns NRF_SUCCESS in both cases.

Here is another odd behavior. If I connect to the device from the nRF Connect app, and then disconnect, and rescan for devices, the device is no longer advertising.

[Edvin]

In both cases, perhaps there is some application error that stops the device directly after the advertisement is started? Have you tried to debug and see what happens? Is the error handler catching something? Does the log say something? If you use a fairly new SDK, the log should say if one of the APP_ERROR_CHECK() catches something.

Is there some way for me to reproduce your issue on an nRF52840 DK?

[Ken A]

This gets more confusing.

I stripped out all unnecessary code, and the problem remains.

It is running on the nRF52840 DK board and I am looking at the disconnect/connect issue, ignoring DFU for now.

The last code I want to remove is for USB. The application requires a USB UART. If I do not initialize USB prior to initializing the softdevice, the function nrf_sdh_enable_request() will fail.