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
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, 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:
DocLib 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
Hi, Andreas.
Thanks. I think I finally got the idea.
One last (hopefully) question:
According to your comment above (... If you want to "keep the DFU functionality", then you have to include a method in your code where you can enter the bootloader.), to include this method in the new app to be uploaded, would it be enough to copy-paste the code you find here, first in the sdk_config.h file (regarding settings with bonds o without bonds) and then the rest (DFU event handler, Power Manager module, and Buttonless Secure DFU Service Initialization) in the main.c file, and in both cases just at the beginning of the existing app code?
Best regards
Hi.
I'm not sure what you are linking to, that link is broken.
However, the should not be any issues in including the DFU Service to your applications existing code, you should only have to follow the guide in DocLib.
Best regards,
Andreas
Hi.
The broken link you mention was pointing to the same document you refer to in your "guide" link. That's why I ask you:
... would it be enough to copy-paste the code you find in the "Buttonless Secure DFU Service" document, that is, copy-pasting (at the top of the sdk_config.h file) the code regarding the settings with bonds o without bonds, and then (at the top of the main.c file), the code regarding the DFU event handler, the Power Manager module and Buttonless Secure DFU Service Initialization?
I know it may seem a silly question for you, but I would very much appreciate your answer (you could call it help) since I am not yet experienced enough in "C" language.
Thanks so much.
Best Regards,
Juan
Hi.
p143 said:... would it be enough to copy-paste the code you find in the "Buttonless Secure DFU Service" document, that is, copy-pasting (at the top of the sdk_config.h file) the code regarding the settings with bonds o without bonds, and then (at the top of the main.c file), the code regarding the DFU event handler, the Power Manager module and Buttonless Secure DFU Service Initialization?
Yes, as I said in my previous reply, you should only have to follow the guide on DocLib, which shows you how to add the Buttonless Secure DFU Service to a BLE application (DFU event handler, Power Manager, Buttonless Secure DFU Service Initialization)
Best regards,
Andreas
