• State Verified Answer
  • Replies 2 replies
  • Subscribers 71 subscribers
  • Views 1305 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 114993
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU advertises as not available

Andrew

I am having a strange issue with running BLE DFU on a project that I can't seem to work out. This an S132 v2 project with SDK11.

If all I do is program the softdevice and the bootloader, I can see the device advertising as "DfuTarg", connect to it through the Android MCP and flash the application no problem.

However, once I have flashed the application and I trigger DFU from the application, the device restarts as expected, and the bootloader is running however it advertises without any information in the advertisement packet and shows up in MCP as "n/a".

While the MCP won't auto connect and start the DFU process by itself since the MAC address has changed, I can manually connect to it while it advertises "n/a" and I can start the DFU this way. This tells me for sure that the bootloader is not totally hosed. and the softdevice started successfully.

I'm curious what in my application, since it seems to be caused by that, could cause this behavior on a reset. Peripherals I am running are PPI and SAADC. WDT is enabled but only when the main application isn't running to see if I need to fully wake up, so it is disabled when the application is fully awake, which is the only time it can be connected to.

Before resetting into bootloader, I call nrf_drv_ppi_channel_disable() and nrf_drv_saadc_uninit().

Parents
  • 0

    @Andrew: If you have bonded to the device, and the central device use public static address, the bootloader will start advertising with directed advertising mode. In this mode there is no advertising payload therefore you will see the device advertise with no name. Please have a look at advertising_start() function in dfu_transport_ble.c The directed advertising mode should last only 1.28 second after that it should advertise normally with whitelist.

    I'm not sure why MCP didn't reconnect automatically. Which MCP version you were testing with ?

Reply
  • 0

    @Andrew: If you have bonded to the device, and the central device use public static address, the bootloader will start advertising with directed advertising mode. In this mode there is no advertising payload therefore you will see the device advertise with no name. Please have a look at advertising_start() function in dfu_transport_ble.c The directed advertising mode should last only 1.28 second after that it should advertise normally with whitelist.

    I'm not sure why MCP didn't reconnect automatically. Which MCP version you were testing with ?

Children
No Data
Related
Terms of service