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
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
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
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
Thanks Andreas.
I'll try that.
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
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
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
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
Hi Juan.
I said wrong to you in the last reply, sorry. I have had a look at the code, and it looks like the Application is responsible for both these services.
Best regards,
Andreas
Hi Andreas.
I understand but, which app are you referring to, the one I've described as "(3)", or the one I've described as "(4)"?
Best Regards,
Juan
Hi Juan.
Sorry, I should have been more clear in my reply, I was talking about Application (3).
Best regards,
Andreas
Hi, Andreas.
Hope you don´t mind if I disagree (just for a while) with your last comment.
I am conscious I almost know nothing about Nordic devices and that you probably know about everything on this subject but:
- I suspect that the Secure DFU Service cannot be generated by the application I was describing as "(3)" in my previous comment, because if you follow the step by step guide you can find here, after flashing through CDC-UART just a SoftDevice and a Secure DFU Bootloader firmware images into a target device, if you scan this device and connect with it (his name being dfu target), you will be already able to detect a DFU Service coming from this device in spite no app has been yet loaded on it. Accordingly, I have to conclude that is the Secure DFU Bootloader the only firmware image responsible for setting up the DFU Service and not the apps I was calling "(3)" and "(4)".
- Regarding the Buttonless Secure DFU Service I am not so sure, but based on the nRF5 SDK v15.2.0 Buttonless DFU Template Application example and the Buttonless Secure DFU Service documentation, I suspect that in fact, is the app I was calling "(4)" in my example (I mean, the one you want to ble-dfu into the target device to replace the previous one I was calling "(3)") the one which really implements the Buttonless DFU Service. This file, according to the referred documents, apart from the main app functionality, will also carry the code to implement the Buttonless Secure DFU Service, and the Bootloader Settings Page.
Would you agree with this point of view?
Thanks for your time,
Regards,
Juan
Hi.
p143 said:Accordingly, I have to conclude that is the Secure DFU Bootloader the only firmware image responsible for setting up the DFU Service and not the apps I was calling "(3)" and "(4)".
No, it is possible to do DFU only with the Secure DFU Bootloader firmware, but you do not use the DFU service in this scenario.
If you read the documentation in the bootloader library, you can read this:
Unknown said:
In the DFU mode, the bootloader activates the DFU transports and the device is ready to receive new firmware. The bootloader enters the DFU mode on the following conditions:
As you can read here, you can do DFU with and without a valid application.
The DFU Service is a part of the Application, and it enables entering DFU mode by the define "NRF_BL_DFU_ENTER_METHOD_BUTTONLESS" from the Application. It is intended to be used in scenarios where there is limited or no physical access to the device, to provide better user experience on devices with limited I/O capabilities, or to automate the process of running a Device Firmware Update from a smart device.
Best regards,
Andreas
