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,

Disclaimer: 
It has been a long time since this ticket was active, and I have not read through the old replies. I'll answer based on the information from your latest reply, but for follow up questions, you should consider creating a new ticket where you summarize all your present issues.

 

cor10 said:

I dont see any output in the Debug Terminal at all. And when the program halts in the Debugger at the NRF_BREAKPOINT_COND; in the Fault Handler of "app_eroor_weak.c", I can see that DEBUG is defined. I notice that there is technically some output in the Debug Terminal: about 6 empty lines.

 What project did you attach the debugger to? The bootloader or the application? 

I believe it is the application, based on the rest of your description. What you should do:

Generate bootloader settings (use nrfutil settings generate --help, and check this description) using the application that you want to debug. 

Program bootloader + softdevice + application + bootloader settings, and then attach the debugger to your application project in SES.

add DEBUG to your preprocessor definitions, and disable optimizations*. Remember to re-generate your bootloader settings if whenever you update the application like this, or do any changes to the application code.

Try to debug, and see where the application fails.

In your application project, did you remember to include the function:

    err_code = ble_dfu_buttonless_async_svci_init();
    APP_ERROR_CHECK(err_code);

[cor10]

Thanks for the reply Edvin. I will make a new ticket and summarize my set up and my bug in more detail, but I have a couple things Id like to mention before doing so to hopefully make it as good of a ticket as possible.

The way I am currently attaching the debugger is as follows:

• I open the DFU secure bootloader example code from the nrf sdk, build it, and download it to my device using the Segger Embedded Studio IDE
• When its on and advertising in DFU mode, I select "Attach Debugger"
• Then I attempt to use the iOS nRF Connect app to write my Buttonless DFU app image .zip package to my device (I use this command "nrfutil pkg generate --hw-version 52 --application-version 1 --application Buttonless_custom.hex --sd-req 0xCB --sd-id 0xCB --key-file private.key Buttonless_custom.zip" which was described in this tutorial https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader)
• From the iPhone app, the Buttonless OTA DFU finishes successfully, yet the Debug Terminal shows nothing and the device never begins advertising my custom Buttonless DFU app.

How would I attach to the bootloader? Whats the difference between attaching the debugger like I have described above and "attaching the debugger to my application project in SES" as you mention?

I am sending only the application image .zip package via nRF Connect. I realize maybe I am making a mistake by not also sending the bootloader and softdevice and bootloader settings along with it. There is a section in the Appendix of that tutorial I linked above called "Combine Application, Bootloader and SoftDevice Image - Bootloader Setting"...I didnt implement this part because I assumed it was extra/optional as I am able to run the default Buttonless DFU app by just sending only the application image via nRF Connect. Is this Appendix Section what you mean when telling me to program the bootloader + softdevice + application + bootloader settings?

Do I need to be sending a merged bootloader/softdevice/application/settings hex image as a combination if I want my custom Buttonless DFU app to run correctly? I am also a little confused as to what the bootloader settings are used for exactly.

And yes, my main() function executes ble_dfu_buttonless_async_svci_init(); as one of the first function calls. Thank you for taking your time to help me with these concepts - its much appreciated

[Edvin]

You should attach the debugger from the Segger Embedded Studio project running your application (the one that you udpdate to using nRF Connect for iOS. It has to do with what addresses the project is looking at. If the bootloader starts the application this is outside the bootloader project, so the bootloader project doesn't know how to handle it.

 

cor10 said:

I realize maybe I am making a mistake by not also sending the bootloader and softdevice and bootloader settings along with it.

 No need to do that.

 

cor10 said:

.I didnt implement this part because I assumed it was extra/optional as I am able to run the default Buttonless DFU app by just sending only the application image via nRF Connect.

 It is optional, but useful for debugging. If you do this, you don't have to perform the DFU every time you want to change something in your application. 

Create a file called test.bat that does this for you, so you can just run it from a cmd window. It should look something like this:

:: compile bootloader and application:
make -C <bootloader_makefile_folder_path>
make -C <application_makefile_folder_path>

nrfutil settings generate <options> settings.hex

nrfjprog -e
nrfjprog --program <softdevice>.hex --verify
nrfjprog --program bootloader.hex --verify
nrfjprog --program application.hex --verify
nrfjprog --program settings.hex --verify

nrfjprog --reset

You can compile using SES if you prefer that instead of the makefiles. 

If you need help to generate the bootloader settings, use "nrfutil settings generate --help" or see the link from my previous reply.

 

cor10 said:

Do I need to be sending a merged bootloader/softdevice/application/settings hex image as a combination if I want my custom Buttonless DFU app to run correctly? I am also a little confused as to what the bootloader settings are used for exactly.

 The bootloader settings are not used to generate an application image. It is used if you want to flash the application directly using the programmer when a bootloader is present. The settings contains a signature that makes the bootloader accept the image. If you try to flash an application and the bootloader without settings, you will see that the application is not starting, because the signature is not present. The signature is generated automatically by the bootloader when you perform the DFU.

This has nothing to do with the original title of this ticket. Please create a new ticket. 

[cor10]

Thank you Edvin. I finally understand what you mean. It took me a while to grasp the concept but your explanation really helped me becuase now I should be able to at least debug it properly! Sorry for not creating a new ticket on this.