Getting error "DFU characteristic not found"

[Di-sheng]

Dear

I am try to perform an  OTA  operation on a dongle of nrf52840 by ble_app_blinky for PCA10059 project   and  light-switch server for PCA10059 project, which works well on the PCA10059.

For the OTA operation, I have a Android smart phone with nRF toolbox , a PCA10056 DK which can be connect to a dongle by swd interface. I use nRF5 SDK_16.0.0 and SDK for MASH 4.0.0.

In these case, the Softdevice will be " s140_nrf52_7.0.1_softdevice"

Step1 : I make a pair keys for this operation by nrfutil command and build  "secure_bootloader_ble_s140_pca10056_debug.emProject" project with the new public_key.

Step2 :  I download the dfu_bootloader which be built last step to  dongle which be clean by "nrfjprog -e"

Step3 :  Make a dfu.zip for ble_app_blinky project by nrfutil command which is

nrfutil pkg generate --hw-version 52 --debug-mode --sd-req 0x00 --sd-id 0xCA --application ble_app_blinky_pca10059_s140.hex --key-file private.key --softdevice s140_nrf52_7.0.1_softdevice.hex ble_app_blinky_pca10059_s140_sd_DBdfu_package.zip

Make a dfu.zip for light-switch server for PCA10059 project by nrfutil command which is

nrfutil pkg generate --hw-version 52 --debug-mode --sd-req 0x00 --sd-id 0xCA --application light_switch_server_nrf52840_xxAA_s140_7.0.1.hex --key-file private.key --softdevice s140_nrf52_7.0.1_softdevice.hex light_switch_server_nrf52840_xxAA_s140_V701_sd_DBdfu_package.zip

Step4 :  Upload those packages to different Dongle separately by DFU of nRF Toolbox on Android smart phone. All of them be successful.

Step5 :  Modify the  ble_app_blinky for PCA10059 project   and  light-switch server for PCA10059 project by exchange LED pins with each other. Repeat step3 to step4. All of them be failure with a error "DFU characteristic not found"

Q1: Is there anything wrong with the process described above?Why does the first update succeed, but then fail (only once?)?

Q2: When  I doing DFU on DFU tools of nrf toolbox on my phone, if I select  "Application" as file type, I have to select an other file as init package. which mean is if I want download an app.hex to chips, an init package will be supported. Because the SES can build a project to generate a hex file and can download the hex file to chip.  For this reason, can I assume that SES also generated the corresponding init package during the build? If the answer is yes, where is the init package?

Q3: About the bootloader setting page, If a donwload a app.hex go through bootloader, a  bootloader setting page will be generated by bootloader. is it correct? 

When I read the post here, I donot uderstand  those words below.

"But in production for example, you may not want to install the application by doing OTA DFU for thousands of device which takes lots of time. The same when you are doing development. You don't want to do DFU for any change you made to your application.

To solve this, we can generate a bootloader setting manually and merge it with the bootloader to trick the bootloader to accept the pre-flashed application. We use nrfutil to generate the bootloader setting and can use mergehex.exe tool to merge the hex files. If you don't want to merge you can flash the setting first then flash the bootloader."

Would you explain the function to me. Some examples will be better for me.

Q5: I want doing  a OTA by a dongle and a PCA10056. which tools can be used on my disktop like the DFU of nrf toolbox on smart phone?  How I can connect the PCA10056 with the desktop(J2 or J3 or others connector)?  Do i need download the dfu project to the PCA10056? Do you have a manual with detail? 

Thanks,

Di-Sheng

[Edvin]

Let me try to summarize this.

You are using the bootloader from the normal SDK (SDK17.0.0) and the application from the Mesh SDK, right?

Q1: Is your issue actually that when you have performed a DFU, and updated the application, then you are not able to perform the DFU again?

If so, that is because your device is not in DFU mode, and there is no way for the application to put it back in DFU mode. I suggest that for now, skip everything Mesh related, and even the dongle. Test the ble_app_buttonless_dfu example on the DK. This example contains a DFU service, which has only one job, put the device back in DFU mode. You need to include this service in your appliation firmware, so that nRF Connect/nRF Toolbox recognizes this service, and uses it to put it back in DFU mode. 

There are alternative methods to put it in DFU mode. This is a bit more tricky on the dongle, because it only has one button, but if you look in the SDK\examples\dfu\secure_bootloader\pca10056_s140_ble example, and look in nrf_bootloader.c -> dfu_enter_check() -> 

    if (NRF_BL_DFU_ENTER_METHOD_BUTTON &&
       (nrf_gpio_pin_read(NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN) == 0))
    {
        NRF_LOG_DEBUG("DFU mode requested via button.");
        return true;
    }

If NRF_BL_DFU_ENTER_METHOD_BUTTON is defined, then it will read that pin on startup, and enter DFU mode if it is pressed. Then nRF Toolbox/nRF Connect can perform another DFU.

Q2:

I have not used nRF Toolbox before for DFU. Perhaps you can try nRF Connect for Android. There you just upload the .zip file, containing the init file and the application image. Either way, you need to create the application image using nrfutil, which will give you a .zip file. Didn't you do this already to perform step 3 and step 4 in your explanation?

Q3:

Yes. That is correct.

Q4: 

The bootloader verifies that the application is signed using the private key. Then it stores this in the bootloader settings. If the application doesn't match what it says in the bootloader settings, it will reject the application. This is a safety mechanism. 

There are two ways of generating bootloader settings. Either performing DFU, so that the bootloader generates the bootloader settings for you, or you can generate them manually using "nrfutil settings generate ...".

Imagine that you are in production of a product, and you need to program 1000 units. Then you probably don't want to program the bootloader using a programmer, and then spend one minute performing the DFU on each device. It is better to program the bootloader + application + bootloader settings using the programmer, as this is much quicker. Therefore you can generate the bootloader settings using the "nrfutil settings generate ..." command, and it will give you the bootloader settings as a hex file, that you can program together with your bootloader and application.

Q5:

I don't understand what you mean. Do you want to update the Dongle or the DK? 

You can use any of them, together with either nRF Connect for Desktop (-> "Bluetooth Low Energy" application) or nrfutil (command: "nrfutil dfu ble ...").

[cor10]

Hello Edvin. Up above you mention that: "This example contains a DFU service, which has only one job, put the device back in DFU mode. You need to include this service in your application firmware, so that nRF Connect/nRF Toolbox recognizes this service, and uses it to put it back in DFU mode"

I found success with the Button-based DFU. Everything works perfectly. Then I tried to build the Buttonless DFU app, and I uploaded it via nRF Connect Mobile (iOS) just like I had been doing with the previous Button-based DFU and test apps. My device successfully advertises itself as "Nordic_Buttonless", but I only see the Generic Access, Generic Attribute, and Nordic UART Primary Services listed in the nRF Connect app. There is no DFU Service nor Characteristic available for me to write to. Going off of what you said above, is there something else I need to edit in the Buttonless BLE DFU app in order to include the DFU service in my application firmware? I am trying to run this Buttonless DFU app as it is in the example with no modification (other than removing the need for bonds), but feel like I havent enabled things properly. Can you help give me some advice on how to resolve this? Thank you :)

[Edvin]

Can you please try to connect to it using nRF Connect for Desktop? The reason I ask you to do this is to check whether the GATT table (list of services and characteristics) is cached in the mobile phone, and hence may not discover the added services. If you don't have any other DKs, you can try to delete the bond information, and turn bluetooth off and back on on the phone. Wait a minute or two before turning it back on. 

Another thing to check is the log from the nRF. Check what the application log is saying. You can use a UART or RTT terminal (based on what log backend your application uses). 

There are a couple of things you should make sure of when you include the buttonless dfu service. First of all, you need to include the buttonless dfu service in services init, like it is done in the ble_app_buttonless_dfu example. Then, you also need to include the function ble_dfu_buttonless_async_svci_init() before you start advertising. The reason for this is that if you don't include this, you will receive a hardfault when you try to enter DFU mode. However, lacking this does not explain the behavior that you are seeing.

I was made aware of this today, but there may be a bug in the nRF Connect -> programmer app, when you program .hex files with different non-connected flash sections, such as the bootloader does. Can you please try to use nrfjprog (nRF Command Line tools) to program the bootloader .hex file. ("nrfjprog --program <bootloader file>.hex --verify

Best regards,

Edvin

[cor10]

I tried the nRF Connect Mobile iOS app on my friends phone, and the Buttonless DFU characteristic was displayed as expected! So the code has been working correctly on the board, but the app fails to reflect the change in services/characteristics. So this confirms your suspicions about the cached GATT table - thank you. How can I avoid this issue moving forward? I tried deleting and re-installing the nRF Connect Mobile app on my iphone to reset this cache, but it actually still has the same problem as before (cant see the Buttonless DFU Characteristic). Thank you, your help is greatly appreciated