uBlox NINA-B302 doesn't advertise its DEVICE_NAME

[p143]

Hi All. 

I am familiarised with NINA-B312 module and I am used to seeing its local name being advertised after switch-on, but while testing a  NINA-B302 I've just bought I can't see any DEVICE_NAME being advertised. Is that normal? Is this due to the factory pre-flashed firmware? The supply voltage is 3,6 volt and the consumption (2,x mV) seems fair enough.  

Thanks in advance

[AndreasF]

Hi Juan.

1) I can unfortunately not now it, I would guess perhaps the name of the device is the advertising name. It is up to the manufacturer to choose, and perhaps it is stated in the datasheet.

2) They could support Nordics DFU service, or their own custom DFU service, it would be up to them to choose. We have no control over their options.

3) Same as above, this depends on what the 3rd party module have implemented, and it is entirely up to the manufacturer of that module.

Most of our customers are product manufacturers, and the end user should contact the manufacturers for questions related to their product, not the chip manufacturer, since we do not have control over what our customers do with our chips.

 Best regards,

Andreas

[p143]

Hi Andreas.

Practising the Secure DFU procedure over a nRF52840 SoC, I've noticed that after you flash the Softdevice and the Secure DFU Bootloader images into the target device, as soon as you flash the app image, if you scan and connect back to the same device, the DFU sign does not show up anymore in the top right of its Service List window, so it looks like you can't make more dfu flashing on it.

If this is the way it should be, is there a way to keep the DFU functionality forever so you could customize your device through BLE as many times as you decide to along its life cycle? 

Thanks for your time.

Best regards,

 

p143/ Juan

[AndreasF]

Hi.

p143 said:

I've noticed that after you flash the Softdevice and the Secure DFU Bootloader images into the target device, as soon as you flash the app image, if you scan and connect back to the same device, the DFU sign does not show up anymore in the top right of its Service List window, so it looks like you can't make more dfu flashing on it.

This is because when you do a DFU, you upload a new Application which does not have the Buttonless Secure DFU Service.

If you want to "keep the DFU functionality", then you have to include a method in your code where you can enter the bootloader.

For example by pressing a button, or looking at the ble_app_buttonless_dfu example.

In the ble_app_buttonless_dfu example, the buttonless secure DFU service is used to enter the bootloader.

Best regards,

Andreas

[p143]

Thanks Andreas.

I'll try that.

[p143]

Hi Andreas.

Before we go more in detail implementing the buttonless secure dfu service and the secure dfu service with and without bonds, let me make a conceptual question.

At the end of the day, which is precisely the firmware image responsible for implementing the two fundamental services I mention above?

- Am I right if I say that the bootloader already in the target device is responsible for the Secure DFU Service implementation?

- Am I right if I say that the new app firmware image to be flashed into the target device to replace the actual target device app using the Secure DFU procedure, is responsible for the Buttonless Secure DFU Service implementation?

Thanks so much.

Regards.

p143/ Juan

[AndreasF]

Hi.

p143 said:

- Am I right if I say that the bootloader already in the target device is responsible for the Secure DFU Service implementation?

 Yes, this is the bootloader.

p143 said:

- Am I right if I say that the new app firmware image to be flashed into the target device to replace the actual target device app using the Secure DFU procedure, is responsible for the Buttonless Secure DFU Service implementation?

 I did not quite understand this question. I'm sorry, can you explain a bit more?

Best regards,

Andreas

[p143]

Sorry, Andreas. I'll try again.

Imagine you have a stand-alone Bluetooth module loaded with  (1) a SoftDevice (2) a Bootloader and  (3) an Application in one side, and a PC with a Connect for PC application and a (4) zip package holding a new app in the other side. Imagine you want to perform a secure dfu procedure in order to upgrade the app I've described as "(3)" with the one described as "(4)".

My question is: which element (among the four above described) is responsible for setting up the Secure DFU Service, and which one is responsible for setting up the Buttonless Secure DFU Service?

Best Regards

Juan