Intermittent DFU Activity

[Brian Shankland]

I've been able to port the DFU process into a C# app running within a Linux gateway.

I'm using the buttonless without Bonds service to enter DFU mode.

The problem I have is that on many occasions after I have sent the command to enter DFU mode I'm not seeing the bootloader advertise so are unable to access its services and characteristics.

Within the bootloader I can see from our LED indicators that the NRF_DFU_EVT_TRANSPORT_ACTIVATED event has been raised, but using the nRF Connect app on my phone I can confirm there are no adverts from the bootloader DFU so it is not just my gateway that is not picking them up.

My gateway only attempts to upgrade one device at a time and is not performing any other connections / snooping at the time the enter DFU command is sent.

This is not specifically limited to a particular device, I have 10 set up and on my last test 6 upgraded (some required 2 or more attempts to get the adverts to start) and 4 did not connect.

Running the test again can change which devices respond and which do not.

I've never seen this when using the nRF toolbox app so suspect it may be how I'm handling the disconnect after sending the DFU command, but it works more often than not so must be very specific.

Can anyone suggest anything that may explain this behaviour or something I could try to increase the chances of the bootloader starting to advertise its DFU availability?

Thanks for any assistance you can provide

[Vidar Berg]

Hi,

NRF_DFU_EVT_TRANSPORT_ACTIVATED is raised when a connection has been established with the device, so that explains why you don't see any advertising. Could it be possible that the gateway is maintaining a connection with the device in the "background"? If so,  can you try to disable the Bluetooth on the gateway to see if it remains connected?

Best regards,

Vidar

[Brian Shankland]

Hello, thanks for quick reply.

In case it matters I'm using Bluex 5.61 in the gateway.

To be sure of myself this event is indicating the connection to the DFU mode of the bootloader so is the one that has the BLE address +1 to my normal device?

If so then it would appear that the stack is holding some previous cache but I'm not sure why it would connect without me directing it to.

After I send and receive the Response for the EnterDFU command to the characteristic SecureDFUButtonlessWithoutBondsCharacteristicUUID  ("8EC90003-F315-4F60-9FB8-838830DAEA50" ) I perform a disconnect which drops the connection to the device, but I could perform a dispose as well to make sure (will try this now).

I'll update with further test results, but this gives me something to investigate,

[Brian Shankland]

Could the connection be from an Active scan?

[Vidar Berg]

Hello,

No, a connection will only be established if the central sends a connection request. Have you tried to just power off the gateway to see if the DFU target remains in the connected state? 

Other things you may try:

1. Use a BLE sniffer (e.g.nRF Sniffer for Bluetooth LE) to find the address of the central that connects.

2. In the bootloader, log the Central address from the BLE_GAP_EVT_CONNECTED event

Brian Shankland said:

To be sure of myself this event is indicating the connection to the DFU mode of the bootloader so is the one that has the BLE address +1 to my normal device?

Yes, it will advertise the  original address +1 when in DFU mode (Buttonless Secure DFU Service without bonds).