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.
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
