how to put in dfu ble mode a wireless only device

[astella]

To the kind attention of Nordic support team,

I've got PCA10056 and PCA10040 default development kits. They are talking each other using using secured gzll, PCA10056 is gzll master and usb connected to pc, 

and PCA10040 is only using gzll as a slave to communicate, it is a wireless device only (app it is not using any softdevice, softdevice it is going to be used by ble bootloader only).

I can start connectivity firmware in PCA10056 when ever I want. Still, PCA10040 needs to know that it has got to enter dfu mode.

The simplest way it is to piggy backing an ACK so to inform PCA10040 to enter dfu mode, but being PCA10056 gzll master it can only wait

to first receive a packet from PCA10040. I'm clear? May I ask to Nordic experts if there are other theoretical ways to get it better?

There is no way gzll master can start a communication? PCA10040 should be in System OFF most of the time, so it is not feasible it to send period messages

in a short period of time.

would it be nice to have slave antenna in low power listening mode to be awaken from special message coming from gazell master, the only time it can start a communication.

Otherwise, we could swap master and slave, but we should be polling out master at very high frequency and it is not the case too.

Do you recommend a practical/theoretical solution? Thank you very much for your attention and please let me know if my question it is not clear enough.

Best regards

[bjorn-spockeli]

astella said:

I've got PCA10056 and PCA10040 default development kits. They are talking each other using using secured gzll, PCA10056 is gzll master and usb connected to pc, 

and PCA10040 is only using gzll as a slave to communicate, it is a wireless device only (app it is not using any softdevice, softdevice it is going to be used by ble bootloader only).

I can start connectivity firmware in PCA10056 when ever I want. Still, PCA10040 needs to know that it has got to enter dfu mode.

The simplest way it is to piggy backing an ACK so to inform PCA10040 to enter dfu mode, but being PCA10056 gzll master it can only wait

to first receive a packet from PCA10040. I'm clear? May I ask to Nordic experts if there are other theoretical ways to get it better?

There is no way gzll master can start a communication? PCA10040 should be in System OFF most of the time, so it is not feasible it to send period messages

in a short period of time.

 Ok, so the issue is that the PCA10056 which is the Gazell Host, needs to wait for the PCA10040, which is the Gazell Device to send a message so that the Host can piggyback the Enter DFU command to the ACK. This is how the protocol is designed, see Gazell Link Layer User Guide

Once enabled, the Host in a Gazell network is always listening, and it is the Device that always initiates a communication. Each packet that a Device sends is required to be acknowledged by the Host. It is possible for the Host to send data to the Device by piggybacking data to an acknowledgement (ACK) packet. Therefore a Host has to wait for a packet from a Device before it can send any data to it.

astella said:

Maybe, before going in lower power mode, PCA10040 could switch and become master, using software. At the sime time PCA10056 could be set as device being informed that PCA10040 is going to be new master. Still, is it possible to receive gzll messages when in low power modes? I don't like the idea to switch devices behavior, I have to say

Yes, switching the roles may be an option. Another alternative could be to run BLE concurrently with Gazell, i.e. the PCA10056 is a BLE Central and the PCA10040 is a BLE Peripheral with a single service with a single characteristic that can be used to trigger DFU mode. 

Best regards

Bjørn

[astella]

Very interesting, thank you for all your kindness. Very nice to know that