Getting error "DFU characteristic not found"

Question

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 · Accepted Answer

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

Edvin · Answer

The Mesh stack has it's own way of sleeping, and uses sd_app_evt_wait() for this. Di-sheng said: How I can add them if they are necessary or how I can remove the checking if they are not necessary? What do you mean by "remove the checking if they are not necessary"? Di-sheng said: Q2: I notice the he light-switch server project of Mesh lacks "power_management_init()" and "gatt_init()" function compared to the BLE project. Is it mean the power_management and gatt block do not be added in the project? This is handled other ways. Di-sheng said: Q1: Would you help me to find why it get a 0x04 error code when the "ble_dfu_buttonless_init()" be executed? ------- The error code of 0x04 was actually obtained by executing "SVCALL" If you look in your sdk_config.h file, you should see a define: NRF_SDH_BLE_VS_UUID_COUNT, which is by default set to 0. Set it to 1. When you do this, your main() -> initialize() -> ble_stack_init() -> nrf_sdh_ble_enable() will print something about changing the RAM start and RAM size. Now, it doesn't do that by default, because the "normal" SDK uses a different logging module than the mesh SDK, and the function that checks the RAM settings is from the normal SDK, so it will not print anything. So there are a few things you need to do. In nrf_sdh_ble.c, add the following things: #include "log.h" #undef NRF_LOG_INFO #undef NRF_LOG_WARNING #undef NRF_LOG_DEBUG #define NRF_LOG_INFO __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, __VA_ARGS__); #define NRF_LOG_WARNING __LOG(LOG_SRC_APP, LOG_LEVEL_WARN, __VA_ARGS__); #define NRF_LOG_DEBUG __LOG(LOG_SRC_APP, LOG_LEVEL_DBG1, __VA_ARGS__); Then, in nrf_sdh_ble_enable() in the same file, add , at the end of all the NRF_LOG_WARNING, NRF_LOG_DEBUG and NRF_LOG_ERROR calls. E.g. change: NRF_LOG_WARNING("Insufficient RAM allocated for the SoftDevice."); to NRF_LOG_WARNING("Insufficient RAM allocated for the SoftDevice. "); Then it should say something about the RAM in your log. In my case it says: , nrf_sdh_ble.c, 249, RAM starts at 0x20002E00 , nrf_sdh_ble.c, 252, RAM start location can be adjusted to 0x20002440. , nrf_sdh_ble.c, 255, RAM size for application can be adjusted to 0x3DBC0. You need to change this in your project settings: Hopefully, that solves the issue. Don't worry about the RAM size. It is not used in the Mesh examples.

Edvin · Answer

cor10 said: Hi Edvin, I dont mean to distract your efforts to help Di-sheng, but I was worried that you didnt see my most recent comment (with all the details) up above. 
 No worries. I am glad you did. 
 Do you see anything in the fault handler? Do you see anything in the log? Try to define DEBUG in your preprocessor definitions in your application, and monitor the log. Do you see any log messages? (Before or after the error?) 
 
 Di-sheng said: 
 Below is what happens when I run the command twice:(I am sure that the COM6 and "nRF5x 92Mesh Light" below are correct) 
 
 C:> nrfutil dfu ble -ic NRF52 -pkg LSS59BLDFU1_s140.zip -p COM6 -n "nRF5x 92Mesh Light" -f 
 Flashing connectivity firmware... Connectivity firmware flashed. 
 C:> nrfutil dfu ble -ic NRF52 -pkg LSS59BLDFU1_s140.zip -p COM6 -n "nRF5x 92Mesh Light" -f 
 Board already flashed with connectivity firmware. 
 
 Would you help me to find what happen here? 
 
 Is that the last thing it says? What does it print if you write the command " nrfutil --version" ? 
 
 BR, Edvin

Getting error "DFU characteristic not found"

Top Replies