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]

cor10 said:

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

 This table is stored on the phone, and turning bluetooth completely off and on (or maybe even turning the phone off and on) typically solves this. It depends a bit on the phone model. 

The usual workaround for this is to include something called the Service Changed service (defined by Bluetooth). The buttonless DFU example contains this service. Search for SERVICE_CHANGED in the buttonless dfu example's sdk_config.h file. What this service does is tell the central when it has added new services, and the phone will then do a new service discovery. The problem is if this service was not included from the beginning.

Another temporary workaround is to change the address of the device when you experiment with different services. You can use sd_ble_gap_addr_get/set():

    ble_gap_addr_t my_addr;
    err_code = sd_ble_gap_addr_get(&my_addr);
    APP_ERROR_CHECK(err_code);
    my_addr.addr[0] += 0x01;
    err_code = sd_ble_gap_addr_set(&my_addr);
    APP_ERROR_CHECK(err_code);

Note that this may mess up the DFU process in some cases, because android phones expect the address of the device to be incremented by one when in DFU mode, and it is done quite similar to this. But turn the bluetooth (or phone if that doesn't work) off and on again, and see if that helps. 

 

Di-sheng said:

Q1. I notice the "ble_app_buttonless_dfu" is an application code, because it occupy application area in the chips after flash it into chips. I read the some information here(Buttonless Secure DFU Service) and here(Buttonless DFU Template Application) in  Infocenter. I think it should be added to my own application project, not dfu bootloader, right? If the answer is yes,  a chip which just have BLE_DFU bootloader and SD can not implement a buttonless ble dfu procession. is it right?--which mean whether we can make a device which can implement Buttonless ble dfu function without a application project like the button ble dfu function?

 It should be added to the application, and not the bootloader project. That is correct. A chip that only has a bootloader and the softdevice will automatically enter DFU mode, since it doesn't have an application. So you don't have to press any buttons. 

 

Di-sheng said:

Q2. Would you like to use the sample project Light-Switch Server or ble_app_blinky as an example to show me how to add Buttonless BLE DFU to it? because I do not know how to generate the "bootloader_secure_ble_debug_without_bonds_s140.hex" which is in "nRF5_SDK_16.0.0_98a08e2\examples\dfu\secure_dfu_test_images\ble\nrf52840" and it seem do not inlude a application code.

 ble_app_blinky. The reason for this is that the light-switch server is a Bluetooth Mesh example. While you can use the "normal" BLE bootloader together with mesh, it also has it's own bootloader solution that is targeted for Mesh. 

I have never used the precompiled .hex files for DFU. I don't really see where one would use them. I suggest you build your own bootloader. In that case, you know what private key you can use to generate application images. The .hex file that you refer to is a bootloader (and softdevice, I believe), but no application. But you do not have the private key that is used to generate the public key that is used in this hex file.

I suggest you start with this guide:

https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader

 

Di-sheng said:

Q3. Can the "mergehex" tools  merge two or more HEX files together without conflict although  their  "SES-->Code-->Linker-->Section PLacement Macros" are same ?

 You can merge .hex files using "mergehex", as long as they don't have overlapping areas. So you can merge bootloader, softdevice and application (and bootloader settings if you like), but you can not merge two applications with the same start address.

[Di-sheng]

Hi Edvin

Thanks for your reply.

I have added buttonless function into ble_app_blinky example of nRF5_SDK_16.0.0_98a08e2  which is for PCA10056. It works very well, and past the testing of DFU without button.

I also try to add the buttonless function to light-switch server example of nrf5_SDK_for_Mesh_v4.0.0_src which is for PCA10056. but I got  an error of building:

 

    implicit declaration of function 'NRF_LOG_INFO'; did you mean 'NRF_GPIO'? [-Wimplicit-function-declaration]

    implicit declaration of function 'NRF_LOG_ERROR'; did you mean 'NRF_LOG_DEFERRED'? [-Wimplicit-function-declaration]

    'err_code' undeclared (first use in this function)

I think I miss some files of SDK in my project which defined error code of SDK.

Q1: Would you help me to find which files I missed.

Q2: Will the function of MESH be affected or destroyed if SDK files are added?

Thanks,

Di-Sheng

[Edvin]

Di-sheng said:

Q2: Will the function of MESH be affected or destroyed if SDK files are added?

 I don't think so.

 

Di-sheng said:

Q1: Would you help me to find which files I missed.

 Look at where they are defined in the examples from the normal SDK. 

But I think you may run into some trouble (I am not sure) if you try to add the log module from the normal SDK to the mesh SDK, since the Mesh SDK already have a logging module. Either remove the calls to NRF_LOG_INFO(), or replace them with the mesh log function.

[Di-sheng]

Hi Edvin

Thanks for your reply.

As I told you that I have completed to add buttonless function to into ble_app_blinky example of nRF5_SDK_16.0.0_98a08e2 for PCA10056 and PCA10059 and all of them works well.

Because the ble of nRF5 SDK is basic of mesh, I think the buttonless function should be supported by the application project of Mesh. I do same thing on to the light-switch server example of Mesh like I did on to blinky example of nRF5 SDK. because the example of Mesh do not use more function of nRF5 SDK, so adding the buttonless function to the Light-Swtich Server example of Mesh is more operant than adding it to the blinky example of nRF5 SDK. The extra operation be showed below:

1. When implement Buttonless Secure DFU Service initializing, because there isnot a services_init() in the main.c of light-switch server example. I add a services_init() and a call in initialize() ,like below:

//Initializing the Buttonless Secure DFU Service

static void services_init(void)

{

ret_code_t         err_code;

ble_dfu_buttonless_init_t dfus_init =

{

.evt_handler = ble_dfu_buttonless_evt_handler

};

err_code = ble_dfu_buttonless_init(&dfus_init);

APP_ERROR_CHECK(err_code);

}

 

static void initialize(void)

{

    __LOG_INIT(LOG_SRC_APP | LOG_SRC_FRIEND, LOG_LEVEL_DBG1, LOG_CALLBACK_DEFAULT);

    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "----- BLE Mesh Light Switch Server Demo -----\n");

    ERROR_CHECK(app_timer_init());

    hal_leds_init();

#if BUTTON_BOARD

    ERROR_CHECK(hal_buttons_init(button_event_handler));

#endif

    ble_stack_init();

services_init();

#if MESH_FEATURE_GATT_ENABLED

    gap_params_init();

    conn_params_init();

#endif

 

    mesh_init();

}

 

2. In mian.c file, add some include files for peer_manager , power management library and dfu driver:

#include "nrf_dfu_ble_svci_bond_sharing.h"

#include "nrf_svci_async_function.h"

#include "nrf_svci_async_handler.h"

#include "ble_dfu.h"

#include "nrf_bootloader_info.h"

#include "nrf_log.h"

#include " nrf_pwr_mgmt.h

3. In sdk_config.h file,add some code below:

#ifndef NRF_PWR_MGMT_ENABLED

#define NRF_PWR_MGMT_ENABLED 1

#endif

4. Add some include directories to optionsàcode(common)àPreprocessoràUser Include Directories:

Add "nRF5_SDK_16.0.0_98a08e2\components\libraries\bootloader" for nrf_bootloader_info.h

Add "nRF5_SDK_16.0.0_98a08e2\components\libraries\bootloader\ble_dfu" for nrf_dfu_ble_svci_bond_sharing.h

Add "nRF5_SDK_16.0.0_98a08e2\components\libraries\svc" for nrf_svci.h

Add "nRF5_SDK_16.0.0_98a08e2\components\libraries\fds" for fds.h

Add "nRF5_SDK_16.0.0_98a08e2\components\libraries\mutex" for nrf_mtx.h

 

I have soluted the problem which was in my last post by include "nRF_log.h" in main.c file. So the light-switch server example with buttonless DFU function past the building. It be flashed to the DK by BLE DFU in frist time, but the application do not start to work, the led1-4 kept on(nomal they should be flashing) and the application code appears to be stuck. there is not adverting.

    For this parts, I have some question below:

Q1:  Since the Mesh protocol is based on BLE, buttonlessDFU supported by BLE should also be available for Mesh applications. Is it correct?

Q2:  Did my above actions of adding Buttonless Dfu to the application cause some conflicts that prevented the application from running? Would you help me to find the reason?

For find the reason, I compare the map in chips by nRFConnect àProgrammertools,please to see the picture(the both DK have been erased by "nRFjprog -e" command)

Chip's MAP of ble_app_blinky with buttonless DFU for PCA10056

: Chip's MAP of light-switch server with buttonless DFU for PCA10056

As we know, The black , red and yellow areas in pic1 and pic2 is for Setting page and MBR-P, bootloader and MBR;

Green A area is for Software.

The ble_app_blinky with buttonless DFU for PCA10056.bin is about 25kByte

The light-switch server with buttonless DFU for PCA10056.bin is about 137kByte

So the Green B area of pic1 is for application.  The green B and C of pic2 is for application.

My question is below:

Q3: What is for the green C of pic1?

Q4: Why doesn't pic2 have this piece which like Green C of pic1? Is it the reason which the application do not run?

 

Thanks

 

Di-Sheng

[Edvin]

Di-sheng said:

For find the reason, I compare the map in chips by nRFConnect àProgrammertools,please to see the picture(the both DK have been erased by "nRFjprog -e" command)

 Those pictures are very (!) small. 

Besides, I don't think that they contain any relevant information.

 

Di-sheng said:

Q1:  Since the Mesh protocol is based on BLE, buttonlessDFU supported by BLE should also be available for Mesh applications. Is it correct?

 Not exactly sure how that would work. The Mesh stack makes things work a bit different.

 

Di-sheng said:

Q2:  Did my above actions of adding Buttonless Dfu to the application cause some conflicts that prevented the application from running? Would you help me to find the reason?

 What conflict? What are your observations? Simply "lack of advertisements", or do you see something in the log from the application indicating that it is not runnning?

Do you use a DK or a custom board? Do you see any log? If you use a DK, what does the LEDs look like? Have you programmed application settings? What nRF5 SDK are you using? How does the flash_manager in your mesh app cope with the bootloader? Does it set aside space for the FDS (if you use that at all)? And does it set aside space for the bootloader?

 

Di-sheng said:

Q3: What is for the green C of pic1?

 I don't know

 

Di-sheng said:

Q4: Why doesn't pic2 have this piece which like Green C of pic1? Is it the reason which the application do not run?

 I don't know.

I can't really see much from the pictures, and besides, I would need to know what you program on the devices, and what you do, for it to make sense. Do you reset the devices?

I think you should not include this like a service as you would do in the "normal" SDK. Look at the function mesh_gatt_init() functions, which adds the service and characteristic using sd_ble_gatts_service_add() and sd_ble_gatts_characteristic_add(), respectively. It may be that you will be fine doing it the way you have done as well, but it depends on what "conflicts" you have. Please check the log from the device. And make sure that it is not stuck DFU mode, because of a mismatch in the bootloader settings.

Best regards,

Edvin