https://devzone.nordicsemi.com/f/nordic-q-a/14994/dfu-advertises-as-not-availableI am having a strange issue with running BLE DFU on a project that I can&#39;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 &quot;DfuTarg&quot;, connect to iten-USTelligent Community 13Mon, 11 Jul 2016 16:54:08 GMThttps://devzone.nordicsemi.com/thread/57211?ContentTypeID=1Mon, 11 Jul 2016 16:54:08 GMT137ad170-7792-4731-bb38-c0d22fbe4515:d7a0f612-11e2-435a-a666-204a61afedf0Andrew<p>I ended up forcing the DFU to only use fast advertising and not directed advertising. I don&#39;t think this is a &quot;fix&quot; but it did solve my specific problem.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/57210?ContentTypeID=1Thu, 07 Jul 2016 10:52:55 GMT137ad170-7792-4731-bb38-c0d22fbe4515:6ff4d646-9df3-4519-a97a-4b92ea1fb9baHung Bui<p>@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.</p> <p>I&#39;m not sure why MCP didn&#39;t reconnect automatically. Which MCP version you were testing with ?</p><div style="clear:both;"></div>