Getting error "DFU characteristic not found"

RE: Getting error "DFU characteristic not found"

cor10 — Fri, 06 Nov 2020 02:05:30 GMT

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.

RE: Getting error "DFU characteristic not found"

Edvin — Thu, 05 Nov 2020 15:15:53 GMT

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.

[quote user="cor10"]I realize maybe I am making a mistake by not also sending the bootloader and softdevice and bootloader settings along with it.[/quote]

No need to do that.

[quote user="cor10"].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.[/quote]

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.

[quote user="cor10"]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.[/quote]

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.

RE: Getting error "DFU characteristic not found"

cor10 — Thu, 05 Nov 2020 10:56:30 GMT

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

RE: Getting error "DFU characteristic not found"

Edvin — Wed, 04 Nov 2020 12:27:12 GMT

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.

[quote user="cor10"]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.[/quote]

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

RE: Getting error "DFU characteristic not found"

cor10 — Tue, 03 Nov 2020 10:41:34 GMT

Hello again Edvin,

I hope you are still able to see this response even after all this time. I have been retasked to figure out whats wrong, so I am resurrecting this thread.

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.

When I "Attach Debugger", I am attaching it to the device after the device has been put into DFU mode. To be specific, I flashed the DFU Secure Bootloader example and triggered DFU mode via a push button (I also tested that it could upload a previous application image correctly before putting it in DFU mode again). While its in DFU mode awaiting my new code, I attach the debugger from the SEGGER Embedded Studio IDE. Then from my iPhone, I connect to the device, and start DFU with the prepared HEX code of my own Buttonless_DFU app code (this is a merge of the standard Buttonless DFU app which has been tested and works, along with the BLE UART example code and the TWI sensor code). From the nRF Connect app on my iPhone, the DFU process finishes and I get a little message saying that the DFU was completed successfully. However, my device never starts advertising again, so I cannot connect to it and run the application. I confirm that it is an issue with the Application Code because I am able to put it back into DFU mode and successfully upload a previous Application Image without any issues and it works as expected. So I must be doing something wrong with the merged Buttonless DFU/BLE Uart/TWI Sensor code.

What else can I do? Is there any other option for me to Debug this? Thank you so much for your help

RE: Getting error "DFU characteristic not found"

Di-sheng — Fri, 28 Aug 2020 17:41:43 GMT

Hi Edvin

Thanks for your reply.

All works!

I just do it again like yesterday. The OTA dfu be performed by nRFUtil command on both of PCA10056 and PCA10059.

I think there maybe is some interferon factor make the dfu breaken yesterday.

Thank you a lots for your patience and precise help!

Best Regard,

Di-Sheng

RE: Getting error "DFU characteristic not found"

Edvin — Fri, 28 Aug 2020 07:56:01 GMT

[quote user="cor10"]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.[/quote]

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

[quote user="SpongeBob"][/quote]

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

RE: Getting error "DFU characteristic not found"

Di-sheng — Fri, 28 Aug 2020 00:00:39 GMT

Hi Edvin

Thanks for your reply!

I have past the buttonless dfu testing for Mesh's light-switch server example on PCA10056 and PCA10059 board.

The buttonless dfu can be performed by Desktop's nRFconnect-->Bluetooth Low Energy tools, cell phone's nRFConnect and toolsbox-->DFU, except the nRFUtil command.

For Mesh's light-Switch Server project, the nRFUtil command does not start the DFU process for either the PCA100056 or the PCA0059 board, but it works for the BLE_app_blinky project nRFUtil command for both board.

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?

Thanks,

Best Regard,

Di-Sheng

RE: Getting error "DFU characteristic not found"

cor10 — Thu, 27 Aug 2020 22:52:28 GMT

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. Basically, I got the buttonless DFU default application working as expected. However, when I add the NUS Service to the Buttonless DFU project (as shown in all my edits below, alongside enabling BLE_NUS in the sdk_config.h), the application faults after the DFU and wont actually run when uploaded to the device.

static ble_uuid_t m_adv_uuids[]         = 
{
    {BLE_UUID_DEVICE_INFORMATION_SERVICE, BLE_UUID_TYPE_BLE},
    {BLE_UUID_NUS_SERVICE, NUS_SERVICE_UUID_TYPE}
};


static void nus_data_handler(ble_nus_evt_t * p_evt)
{
    //Basic default implementation from the ble_app_uart project
}


static void services_init(void)
{
    // NOTE: These lines of code have been ADDED to the default implementation!
    ble_nus_init_t     nus_init;

    // Initialize NUS.
    memset(&nus_init, 0, sizeof(nus_init));

    nus_init.data_handler = nus_data_handler;

    err_code = ble_nus_init(&m_nus, &nus_init);
    APP_ERROR_CHECK(err_code);
}

I have also tried to "Attach Debugger" when my device is in DFU state so that I can see what happens when it fails to start my merged buttonless DFU + UART application after a successful OTA DFU. When I watch this debugger, nothing happens except the debugger quits and the Segger Embedded Studio displays the app_timer2.c file, specifically leaving the cursor at the "static uint64_t get_now(void)" function. Not sure if that helps, but I would love any tips or recommendations you have to help me merge the Buttonless DFU project with the BLE UART project. Thank you for the help :)

RE: Getting error "DFU characteristic not found"

Edvin — Thu, 27 Aug 2020 07:22:46 GMT

The Mesh stack has it's own way of sleeping, and uses sd_app_evt_wait() for this.

[quote user="SpongeBob"]How I can add them if they are necessary or how I can remove the checking if they are not necessary?[/quote]

What do you mean by "remove the checking if they are not necessary"?

[quote user="SpongeBob"]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?[/quote]

This is handled other ways.

[quote user="SpongeBob"]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"[/quote]

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 \n, 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.\n");

Then it should say something about the RAM in your log. In my case it says:

<t:       8299>, nrf_sdh_ble.c,  249, RAM starts at 0x20002E00
<t:       8302>, nrf_sdh_ble.c,  252, RAM start location can be adjusted to 0x20002440.
<t:       8306>, 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.

RE: Getting error "DFU characteristic not found"

Di-sheng — Wed, 26 Aug 2020 23:17:46 GMT

Hi Edvin

I do debug the project follow the way that you said last post. Finally, the code stay in " sleep_forever() " function , because err_code =0x04 be got from "SVCALL(SD_BLE_GATTS_RW_AUTHORIZE_REPLY, uint32_t, sd_ble_gatts_rw_authorize_reply(uint16_t conn_handle, ble_gatts_rw_authorize_reply_params_t const *p_rw_authorize_reply_params));"

The link below is the debug tracking in word format.

/cfs-file/__key/communityserver-discussions-components-files/4/Mesh-buttonless.docx

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"

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?

How I can add them if they are necessary or how I can remove the checking if they are not necessary?

Thanks,

Best Regards,

Di-Sheng

RE: Getting error "DFU characteristic not found"

Edvin — Wed, 26 Aug 2020 07:32:44 GMT

So LED1-4 is constant on. That is an important observation. That means that the bootloader accepts the application and start it.

LED1-4 turned on is the error indication in a mesh application.

In Segger Embedded Studio, which you are using, there is an option to "attach debugger":

If you do this, it means you can debug without uploading any software to the DK, which means that the bootloader will not reject the application.

Try this, and see if you get any log output. What does the log say? If you don't get any log output, try to add some logs in the start of the application, e.g. "start". Do you see logs before you add the bootloader?

Either way, you can also try to set breakpoints, to see whether a function is executed or not. Where does the application stop?

BR,

Edvin

RE: Getting error "DFU characteristic not found"

cor10 — Wed, 26 Aug 2020 01:37:45 GMT

Thank you for your tips on this. Everything you mentioned proved to be true. I have to turn on and off my phone to refresh the GATT table, and if the Service Changed option is set from the beginning, it works as expected.

Now that I confirmed that the default buttonless DFU example works as is, I have merged my previous ble_app_uart project with the buttonless DFU template. I have everything included and it builds/compiles without error.

However, when I try to load this merged application onto my device, it doesnt run...something is faulting. When I try and use the debugger, it never successfully starts....usually when I run Build and Debug, it loads the code onto the device, and then prompts me with a Start button to begin Debugging. However, the issue with my merged Buttonless DFU/UART project is that the debugger never presents me with a Start button to click, as if its already running (I see the Pause button instead of Play in the Segger Embedded Studio). So this tells me that something is faulting before the Debugger can even start properly. I tried to see where this behavior is coming from since the dafault example works fine, and so I simply added the NUS Service UUID in 'm_adv_uuids[] as a first step, and this is enough to replicate the behavior Im talking about.

static ble_uuid_t m_adv_uuids[]         = 
{
    {BLE_UUID_DEVICE_INFORMATION_SERVICE, BLE_UUID_TYPE_BLE},
    {BLE_UUID_NUS_SERVICE, NUS_SERVICE_UUID_TYPE}
};

What would you recommend is the best way to resolve this issue? There must be some configuration issue that I am missing with the overlapping DFU and UART projects. When merging the 2 SDK Config files, there were only a few instances where the two files had different setting values. Specifically, these conflicting settings were:

#define PEER_MANAGER_ENABLED
- 1 in the Buttonless DFU, 0 in the UART application
#define PM_CENTRAL_ENABLED
- 0 in the Buttonless DFU, 1 in the UART application
#define BLE_DFU_ENABLED 1
- This needs to be set to 1, so ignoring
#define CRC16_ENABLED
- 1 in the Buttonless DFU, 0 in the UART application
#define FDS_ENABLED
- 1 in the Buttonless DFU, 0 in the UART application
#define NRF_FSTORAGE_ENABLED
- 1 in the Buttonless DFU, 0 in the UART application
#define NRF_PWR_MGMT_CONFIG_AUTO_SHUTDOWN_RETRY
- 1 in the Buttonless DFU, 0 in the UART application
#define NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED
- 1 in the Buttonless DFU, 0 in the UART application
#define NRF_LOG_BACKEND_RTT_ENABLED
- 0 in the Buttonless DFU, 1 in the UART application
#define NRF_LOG_DEFAULT_LEVEL
- 3 in the Buttonless DFU, 4 in the UART application
#define NRF_SDH_BLE_GAP_DATA_LENGTH
- 27 in the Buttonless DFU, 251 in the UART application
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE
- 23 in the Buttonless DFU, 247 in the UART application

I also changed NRF_SDH_BLE_VS_UUID_COUNT to be 2 (previously 1) for both DFU and UART, and changed NRF_SDH_BLE_SERVICE_CHANGED to 1 (previously 0).

Does anything seem suspicious here? Thank you so much for you time and help with this.

RE: Getting error "DFU characteristic not found"

Di-sheng — Tue, 25 Aug 2020 23:29:08 GMT

Hi Edvin

Thanks for your reply, I am sorry, I didn't make the question clear.

I have just successfully completed the Buttonless Dfu experiment based on the BLE_app_blinky example on the DK(PCA10056) board.So I tried to do the Buttonless DFU experiment on the light-Swtich Server example of Mesh on the DK(PCA10056) board in the same way.

Before your reply, I always thought that the method of adding buttonless Dfu function to the application must also support ble application and Mesh application. Through your reply, I realize that may be not ture. However, from your reply, I think it is still necessary to ask you to look at the process, which can help me to figure out many problems

Software stack:

nRF5_SDK_16.0.0_98a08e2
nrf5_SDK_for_Mesh_v4.0.0_src

Soft device: S140

Soft tools:

SES 4.22
nRF Connect--> Bluetooth Low Energy
nRFutil
nRFjprog
nRF Connect-->Programmer

Hardware is 2 pcs DK(PCA10056). One of them is used as PDK for ble dfu, which be programmed the pca10056_s140_ble_debug project (nRF5_SDK_16.0.0_98a08e2\examples\dfu\secure_bootloader\pca10056_s140_ble_debug) as dfu bootloader. The other DK is a target board, which be programmed the same dfu bootloader, after it be erased by "nrfjpro -e" command.

Dfu Prepare:

A ZIP file will be used for updating via " nRF Connectà Bluetooth Low Energy " and PDK to the target DK, which is in DFU mode after writing to boot Loader but before writing to the application.

The zip file generation command is as follows:

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

Note:the publice key of bootloader is come from the private.key, so all key is match.

"s140_nrf52_7.0.1_softdevice.hex" is the softdevice which come from " nRF5_SDK_16.0.0_98a08e2"

" light_switch_server_nrf52840_xxAA_s140_7.0.1.hex" is the application project which is a example of mesh and be modified for adding buttonless dfu function according to here instructions with some extra operation (please see my last post) which are adding some include files and include directories into the project for eliminate compilation errors.

Dfu Process:

After target Dk power on, I can find a device which device name is " DFU Targ by " nRF Connect--> Bluetooth Low Energy " and PDK. Connecting it and DFU ZIP file will be completed. all process will be ok like I do blinky example.

Result:

When DFU update is completed, LED1-4 flashes together under normal conditions, and then the device named "nRF5 Mesh Light" can be found through " nRF Connect--> Bluetooth Low Energy " and PDK. But now it is only LED1-4 that is lit together, and it is always on, and any information of this device is also found through " nRF Connect--> Bluetooth Low Energy " and PDK.

Because only project application project (light_switch_server_nrf52840_xxAA_s140_7.0.1.hex) was modified, the rest parts such as Bootlader and Softdevice were the same as Button DFU before, and since BLE DFU was adopted, the bootloader setting page of the application was generated by bootloader, so the SES's "Section Placement Macros" of the application project do not be modified, and the contents of "Section Placement Macros" were still as follows:

FLASH_PH_START=0x0
FLASH_PH_SIZE=0xf8000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x3f000
FLASH_START=0x27000
RAM_START=0x20002e00

That is all I have to say about my attempt to add the Buttonless function to the Mesh example.

My questions is follow:

Q1. I think I understand the difference between the Mesh implementation mechanism you mentioned and ble. In other words, the Buttonless function added according to BEL will not only not start the application into DFU mode, but also disturb the normal operation of the Mesh application. Is that correct?

Q2. If I still want add ble buttonless dfu to mesh's application, how should I do? What are the specific steps?Any special attention?Do you have any recommendations?

Q3. Based on the buttonless function process and results of the mesh application described above, can you determine the cause? How can I make sure where it stuck ?

Q4 I'll take a look at the SD_ble_gatts_service_add () and SD_ble_gatts_characteristic_add () functions, based on what you said in your last post. You also side "Please check the log from the device.". Would you like to explain that to me about how and what can I do?

Q5 You said last post "Does it set aside space for the FDS (if you use that at all)? And does it set aside space for the bootloader?". What does FDS mean? and What does "does it set aside space for the bootloader?" mean?

Then I compare two chips maps by nRFConnect -->Programmertools, One of them is a ble_app_blinky example for PCA10056 with successful buttonless dfu function, The other one is the light-switch server of Mesh with unsuccessful buttonless dfu function.

PIC1: nrf52840 map for ble_app_blinky with buttonless dfu of PCA10056.png

PIC2:nrf52840 map for light-switch server with buttonless dfu of PCA10056.png

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

Best Regards,

Di-Sheng

RE: Getting error "DFU characteristic not found"

Edvin — Tue, 25 Aug 2020 09:26:25 GMT

[quote user="SpongeBob"]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)[/quote]

Those pictures are very (!) small.

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

[quote user="SpongeBob"]Q1: Since the Mesh protocol is based on BLE, buttonlessDFU supported by BLE should also be available for Mesh applications. Is it correct?[/quote]

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

[quote user="SpongeBob"]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?[/quote]

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?

[quote user="SpongeBob"]Q3: What is for the green C of pic1?[/quote]

I don't know

[quote user="SpongeBob"]Q4: Why doesn't pic2 have this piece which like Green C of pic1? Is it the reason which the application do not run?[/quote]

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

RE: Getting error "DFU characteristic not found"

Di-sheng — Tue, 25 Aug 2020 02:23:40 GMT

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:

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();

}

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

In sdk_config.h file,add some code below:

#ifndef NRF_PWR_MGMT_ENABLED

#define NRF_PWR_MGMT_ENABLED 1

#endif

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

RE: Getting error "DFU characteristic not found"

Edvin — Thu, 20 Aug 2020 11:25:47 GMT

[quote user="SpongeBob"]Q2: Will the function of MESH be affected or destroyed if SDK files are added?[/quote]

I don't think so.

[quote user="SpongeBob"]Q1: Would you help me to find which files I missed.[/quote]

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.

RE: Getting error "DFU characteristic not found"

Di-sheng — Thu, 20 Aug 2020 00:48:17 GMT

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

RE: Getting error "DFU characteristic not found"

Edvin — Mon, 17 Aug 2020 08:00:32 GMT

[quote user="cor10"]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).[/quote]

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.

[quote user="SpongeBob"]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?[/quote]

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.

[quote user="SpongeBob"]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.[/quote]

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

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

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.

RE: Getting error "DFU characteristic not found"

Di-sheng — Sat, 15 Aug 2020 00:18:08 GMT

Hi Edvin

Thanks for your reply, That is very powerful.

I have completed the BLE OTA DFU in button mode, which include from PDK to DK and Dongle by Bluetooth Low Energy and nRFUtil of desktop and nRFconnect and Toolbox of smart phone. All of them works well, which include a pca10059_s140_ble_debug for PCA10059.

Now I am doing the buttonless DFU . Would you like to help me for some questions below.

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?

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.

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

Thanks,

Di-Sheng

RE: Getting error "DFU characteristic not found"

cor10 — Fri, 14 Aug 2020 23:12:12 GMT

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

RE: Getting error "DFU characteristic not found"

Edvin — Fri, 14 Aug 2020 12:48:03 GMT

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

RE: Getting error "DFU characteristic not found"

cor10 — Fri, 14 Aug 2020 08:08:56 GMT

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

RE: Getting error "DFU characteristic not found"

Edvin — Tue, 11 Aug 2020 12:31:32 GMT

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