OTA Thread DFU: Merge SDK example with custom application

RE: OTA Thread DFU: Merge SDK example with custom application

Jørgen Holmefjord — Tue, 08 Jun 2021 14:16:54 GMT

What happens inside app_start()? Does the bootloader run until jump_to_addr()?

What is the value of the vector_table_addr parameter?

Can you share the full project? Is it reproducable on a nRF52840 DK (i.e., are you using the default QSPI flash chip)?

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Sat, 22 May 2021 17:42:03 GMT

Hi all,

I managed all the error in the bootloader.

Now, I can load from QSPI the fw in the flash and I can pass all hash&crc checks.

The bootloader can run smootlhy until the last step ( app_start(vector_table_addr); ).

I attach a screenshot from debugger:

the bank0 information are correct
the FW at 0x27000 (just after SD) is correct
the bootloader can run until last step

Now, I'd like to know why the hell the board DOESN'T START THE APP.

The board just stucks in the BL!!

Can someone support me please?

Thanks

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Tue, 18 May 2021 10:02:03 GMT

I have some problems debugging the bootloader.

I know that I have to use "target" -> "attach debugger" to debug the bootloader when the new application has to be validated and activated.

After flashing components (BL + SD + APP), the app is running and if I attach the debugger from bootloader project I have this behaviour:

Obviusly, the app stops running and I can't debug the bootloader project.

How am I supposed to use "attach debugger" feature?

Thanks,

Alessio

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Mon, 17 May 2021 11:00:41 GMT

Hi all,

I'm facing the bootloader modifications.

I can't get if I have to update bootloader to let him use SD or not.

In the application side, I updated the code to work with the SD (because my native application had already SD feature) but with the bootloader I have a lot of problems.

I'm using:

examples\thread\dfu\bootloader\pca10056\blank\ses

Does the bootloader have to exploit SD to read/write flash (fstorage)?

I want to read settings from my main flash and DFU chunks from my external QSPI flash memory

Thanks,

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Thu, 13 May 2021 16:22:08 GMT

##### UPDATE #####

Hi all,

finally I completed the merge of the DFU client in my custom application.

I added the feature of data storage (new FW package) in the external flash memory that is present in the Adafruit nrf52840 board (gd25q16).

Now, I have to deal with the bootloader part.

As I got so far, once the FW download ends and the board is rebooted, the bootloader is in charge to copy the new FW data from bank1 to bank0 and start the new FW (Am I right?).

Any suggestions on this? Where do I start to complete this task?

Thanks,

Alessio

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Thu, 06 May 2021 14:52:03 GMT

Hi all!

I'm trying to develop the dual bank approach exploiting external QSPI flash memory (GD25Q16, the one that is in the Adafruit nrf52840 board).

I merged the QSPI drivers with the DFU application but it is not working as usual.

First, I modified the nrf_dfu_cache_prepare() function setting the bank1 address as 0x00 (I want to start store the FW image at the beginning of the QSPI flash memory)

Then, I modified the nrf_dfu_flash_init(), nrf_dfu_flash_store() and nrf_dfu_flash_erase() functions to exploit QSPI drivers instead of fstorage ones.

If I start a DFU process, there are several problems:

even if the cache address is 0x00, the write address still remains 0xC5000 (the end of the current FW)
during erase/write procedures the "queue usage" parameter increases. That's because I don't know how to use this callback function (QSPI drivers don't request a callback function, fstorage ones do)

I highlighted the issues explained above in the debug log I can see from my application.

The process stucks with the error

Validate trigger: DFU already in progress (s:DFU_DOWNLOAD_FIRMWARE)

after the first write operation.

Can anyone help me please?

May I have to edit also the bootloader? I thought that only application works in this first DFU part (FW download) and that the BL comes in only after the postvalidation (at the end of the FW downloading part).

Can I have a clarification about that?

Thanks,
Alessio

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Thu, 29 Apr 2021 10:18:56 GMT

Yes, I adapted the bootloader for the dongle editing the makefile

PROJECT_NAME     := thread_secure_dfu_bootloader_secure_dfu_blank_pca10059
CFLAGS += -DBOARD_PCA10059
ASMFLAGS += -DBOARD_PCA10059

and I usually do an erase operation before flashing SD, BL and APP (I have a dongle with the jlink connector soldered)

nrfjprog -f nrf52 --eraseall

I can't get if the problem

[quote userid="102652" url="~/f/nordic-q-a/73401/ota-thread-dfu-merge-sdk-example-with-custom-application/307325#307325"]

If I generate the DFU package with --sd-req 0x00 the DFU image is downloaded and restarted correctly.
If I generate the DFU package with --sd-req 0xCA the DFU image is downloaded correctly by application but then it is not restarted (by bootloader I guess).

[/quote]

comes from the bootloader that is not compatible with SD or from my DFU image that is a dummy blinky example (that does not include/use SD)

RE: OTA Thread DFU: Merge SDK example with custom application

Jørgen Holmefjord — Wed, 28 Apr 2021 19:55:08 GMT

Did you mean: "examples/thread/dfu/bootloader/pca10056/blank/armgcc"?

Or have you created your own Thread DFU bootloader project with support for the nRF52840 Dongle? Have you connected a J-Link debugger to the dongle and erased the bootloader that comes with it?

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Wed, 28 Apr 2021 19:44:51 GMT

Hi Jorgen,

[quote userid="102652" url="~/f/nordic-q-a/73401/ota-thread-dfu-merge-sdk-example-with-custom-application/307325#307325"]

I had to set the macro "BLE_STACK_SUPPORT_REQD" because it is the only way I found to initialize the nrf_fstorage_init() with nrf_fstorage_sd. Otherwise, the standard configuration exploits nrf_fstorage_nvmc that is incompatible with the SD (as I understood).

Now, I have the two versions working the same (the switched one needs nrf_fstorage_nvmc, the multiprotocol one needs nrf_fstorage_sd).

[/quote]

As I said before, your suggestion is exactly what I did in my application preprocessor symbols.

What about the bootloader?

[quote userid="102652" url="~/f/nordic-q-a/73401/ota-thread-dfu-merge-sdk-example-with-custom-application/307325#307325"]

So, I think that, if I put --sd-req 0xCA, the DFU image is placed correctly at 0x27000 (end of SD) but the bootloader (I'm using the one in the DFU example, that probably is not supposed to work with a SD) looks for new FW at 0x1000 (end of MBR, start of the FW if you DON'T use SD). Obviously, it can't find the FW and so it can't restart the application.

On the contrary, if I put --sd-req 0x00, the DFU image is placed at 0x1000 (that is wrong because it overwrites my SD) and the bootloader (that is supposed to work without SD and looks for the new FW at 0x1000) is able to find the new application and it can restart it.

[/quote]

May this issue be related to wrong bootloader settings?

I'm using

examples/thread/dfu/bootloader/pca10059/blank/armgcc

Can this bootloader be used with SD or should I modify something?

Thanks,

Alessio

RE: OTA Thread DFU: Merge SDK example with custom application

Jørgen Holmefjord — Wed, 28 Apr 2021 19:15:52 GMT

Hi,

If the softdevice is enabled, you need to use the softdevice backend for Fstorage. The softdevice restricts access to the NVMC peripheral and you need to access it through the softdevice flash API.

Try setting BLE_STACK_SUPPORT_REQD in your project preprocessor symbols. This should switch to the softdevice backend. There may be other issues caused by this symbol not being set as well.

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Wed, 28 Apr 2021 19:14:33 GMT

################ EDIT ################

Finally I have the multiprotocol version working.

Now, I have the two versions working the same (the switched one needs nrf_fstorage_nvmc, the multiprotocol one needs nrf_fstorage_sd).

As I got so far, the thread DFU process is split between application and bootloader:

Application downloads the new DFU image in bank1
When the download is over, bootloader switch data in bank1 with data in bank0 and restarts the application

Let me know please if I miss something.

So, at the moments it seems that the DFU part related to application (packets download) works well. I think that I have issues with the DFU part related to bootloader.

I keep finding the same problem that I saw with the switched version.

If I generate the DFU package with --sd-req 0x00 the DFU image is downloaded and restarted correctly.
If I generate the DFU package with --sd-req 0xCA the DFU image is downloaded correctly by application but then it is not restarted (by bootloader I guess).

I know that my scenario should work with --sd-req 0xCA (that is the ID of my SD).

Does it make sense to you? Should I edit something in the provided bootloader to adapt it to work with a SD? In this case, can someone provide the necessary editings?

Thanks,

Alessio

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Wed, 28 Apr 2021 15:46:01 GMT

Hi Jorgen,

I had a debug session to get more in details the difference between my 2 applications.

I found that my switched application and my multiprotocol one have different behaviours here:

Both applications erase the settings page, the switched one go trought this function without any problems and then starts the DFU, the multiprotocol one doesn't arrive at the breakpoint and crash before.

Any ideas? May I need to do any updates in the bootloader? I'm using exactly the one used in the Thread DFU example. Or maybe I need to change this function in DFU files:

because nrf_fstorage_erase() implements nrf_nvmc_page_erase() that maybe goes in conflict with the SD?

Thanks,

Alessio

RE: OTA Thread DFU: Merge SDK example with custom application

Jørgen Holmefjord — Wed, 28 Apr 2021 10:20:23 GMT

Hi,

I believe that this post sums up your questions and options regarding single bank DFU.

Do you support updates over BLE in the bootloader in any of the versions, or only over Thread? The sd_req option may not be needed it this is not supported, see Updates without a SoftDevice.

I think the issue in the second application is that the "Bank 0 size" field is set to 0. This indicates that there is no code in bank 0, and the new application is placed directly after the softdevice (which has a size of 0x27000). You mention before tha the Bootloader settings page (0xFF000) was erased, can you try to read out this page to see if it is blank or has incorrect size field for bank 0?

>nrfjprog --memrd 0xFF000 --w 32 --n 0x1000
0x000FF000: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x000FF010: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x000FF020: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF   |................|

If the settings-page is valid, you may need to debug your application to see where the fields are cleared in s_dfu_settings.

Best regards,
Jørgen

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Mon, 26 Apr 2021 19:29:21 GMT

UPDATE

I want to summarize the main issues I'm facing at the moment so people can help with a clear vision of my scenario

More theoretical issue: can I implement single-bank approach exploiting Thread DFU example? I don't have enough space in my flash to store both old FW and new DFU image so dual-bank approach is unfeasible. Any workaround to this?
Let's pretend that I can implement a dual bank approach (I'm using a dummy DFU image so it can fit in my flash and I can isolate the issue explained above). I had some tries with two version of my application: an older one that exploits BLE and Thread protocol in a "switched mode" and a more recent version where I implemented the multiprotocol approach (BLE and Thread together).
The DFU starts correctly with the first version (the older one). It works (reset and run the new application) only if I put --sd-req 0x00 when I generate the package, if I put --sd-req 0xCA (that is the SD I'm using in my application) the DFU starts and ends, but the new application is not run.

Instead, the DFU doesn't start at all with the second version (the more recent one with the multiprotocol implementation)

The main difference between the two versions is how I exploit the SD, so I'm pretty confident that my issue is someway related to SD.
Moreover, as you can see from debug logs, the cache_adress changes between the two versions: in the switched case it is 0xC2000 (that is the first free flash page after my current flashed fw), in the multiprotocol case it is 0x27000 (that is the start of my current flashed fw). I think 0xC2000 should be the correct adress in a dual-bank scenario (let me know if I'm wrong), but I can't get why in the multiprotocol version the starting adress is 0x27000 (I think the solution crashes because the application tries to overwrite itself someway).

Thanks in advance,

Alessio

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Mon, 26 Apr 2021 09:31:12 GMT

Hi Jorgen,

[quote userid="14926" url="~/f/nordic-q-a/73401/ota-thread-dfu-merge-sdk-example-with-custom-application/306593#306593"]

Thread secure DFU only supports dual-bank DFU. In order to support single-bank DFU, the transport layer (Thread protocol in this case) must be supported in the bootloader, if not you risk "bricking" the device if the DFU process fails. The OpenThread libraries are too large to fit in the bootloader, and are not a separate module (like for instace our BLE softdevice, which is stored in a separate location in flash, fully detached from the application. So for Thread DFU, the application is not stopped until the entire new application is received. When the application is received, the application will reset and bootloader will handle swapping of application images.

[/quote]

So are you saying that I can't perform a single bank DFU with Thread protocol?

How can I manage the issue that in the flash I can't storage the current FW and the DFU image (lack of memory space)?

I can attach some debug log about my error

Thanks,

Alessio

EDIT:

I tried with a DFU image that fits my memory space with the NRF_DFU_FORCE_DUAL_BANK_APP_UPDATES macro set and I have the crash problem anyway. So probably I'm facing at the moment a different problem than the lack of memory space.

RE: OTA Thread DFU: Merge SDK example with custom application

Jørgen Holmefjord — Fri, 23 Apr 2021 15:46:57 GMT

Hi,

[quote user="AS_Kalpa"]unfortunatly at the moment I can't share the project with third parties, I need to check the policy with my company.[/quote]

Ok, it would help a lot if your could be allowed to share the project. Everything is treated confidentially by Nordic, and other users will not have access to the content of this ticket if I convert it to private.

[quote user="AS_Kalpa"]Do you think this could have an impact?[/quote]

It could be related, check out the suggestions in this post.

[quote user="AS_Kalpa"]Another question, I thought that the DFU process (at least the single bank approach) was carried out by bootloader (so the application is stopped). So what's the meaning of this macro? [/quote]

The DFU libraries contains code for both Bootloader and application parts of the process. This config is used to determine if the build is an application or the bootloader.

[quote user="AS_Kalpa"]And why it is called "background" DFU if the application is stopped anyway?[/quote]

[quote user="AS_Kalpa"]If the application is carrying out the DFU process is pretty easy to understand that I can't use the single bank approach (since che app can't erase itself if it is running). I need some clarifications about this.[/quote]

Yes, the application is responsible for receiving the DFU image. Bootloader is responsible for swapping images.

Best regards,
Jørgen

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Fri, 23 Apr 2021 15:30:30 GMT

Hi Jorgen,

unfortunatly at the moment I can't share the project with third parties, I need to check the policy with my company.

I compared the Thread DFU client sdk_config (that I copied-pasted in my project) with the one of my project. I found these main differences (other small differences are about LOG but I think they are useless)

This is what I have in the Thread DFU client sdk_config:

// <e> MEM_MANAGER_ENABLED - mem_manager - Dynamic memory allocator
//==========================================================
#ifndef MEM_MANAGER_ENABLED
#define MEM_MANAGER_ENABLED 1
#endif
// <o> MEMORY_MANAGER_SMALL_BLOCK_COUNT - Size of each memory blocks identified as 'small' block.  <0-255> 

#ifndef MEMORY_MANAGER_SMALL_BLOCK_COUNT
#define MEMORY_MANAGER_SMALL_BLOCK_COUNT 8
#endif

// <o> MEMORY_MANAGER_SMALL_BLOCK_SIZE -  Size of each memory blocks identified as 'small' block. 
// <i>  Size of each memory blocks identified as 'small' block. Memory block are recommended to be word-sized.

#ifndef MEMORY_MANAGER_SMALL_BLOCK_SIZE
#define MEMORY_MANAGER_SMALL_BLOCK_SIZE 128
#endif

// <o> MEMORY_MANAGER_MEDIUM_BLOCK_COUNT - Size of each memory blocks identified as 'medium' block.  <0-255> 

#ifndef MEMORY_MANAGER_MEDIUM_BLOCK_COUNT
#define MEMORY_MANAGER_MEDIUM_BLOCK_COUNT 4
#endif

// <o> MEMORY_MANAGER_MEDIUM_BLOCK_SIZE -  Size of each memory blocks identified as 'medium' block. 
// <i>  Size of each memory blocks identified as 'medium' block. Memory block are recommended to be word-sized.

#ifndef MEMORY_MANAGER_MEDIUM_BLOCK_SIZE
#define MEMORY_MANAGER_MEDIUM_BLOCK_SIZE 256
#endif

// <o> MEMORY_MANAGER_LARGE_BLOCK_COUNT - Size of each memory blocks identified as 'large' block.  <0-255> 

#ifndef MEMORY_MANAGER_LARGE_BLOCK_COUNT
#define MEMORY_MANAGER_LARGE_BLOCK_COUNT 2
#endif

// <o> MEMORY_MANAGER_LARGE_BLOCK_SIZE -  Size of each memory blocks identified as 'large' block. 
// <i>  Size of each memory blocks identified as 'large' block. Memory block are recommended to be word-sized.

#ifndef MEMORY_MANAGER_LARGE_BLOCK_SIZE
#define MEMORY_MANAGER_LARGE_BLOCK_SIZE 1024
#endif

This is what I have in my application:

// <e> MEM_MANAGER_ENABLED - mem_manager - Dynamic memory allocator
//==========================================================
#ifndef MEM_MANAGER_ENABLED
#define MEM_MANAGER_ENABLED 1
#endif
// <o> MEMORY_MANAGER_SMALL_BLOCK_COUNT - Size of each memory blocks identified as 'small' block.  <0-255> 


#ifndef MEMORY_MANAGER_SMALL_BLOCK_COUNT
#define MEMORY_MANAGER_SMALL_BLOCK_COUNT 64
#endif

// <o> MEMORY_MANAGER_SMALL_BLOCK_SIZE -  Size of each memory blocks identified as 'small' block. 
// <i>  Size of each memory blocks identified as 'small' block. Memory block are recommended to be word-sized.

#ifndef MEMORY_MANAGER_SMALL_BLOCK_SIZE
#define MEMORY_MANAGER_SMALL_BLOCK_SIZE 64
#endif

// <o> MEMORY_MANAGER_MEDIUM_BLOCK_COUNT - Size of each memory blocks identified as 'medium' block.  <0-255> 


#ifndef MEMORY_MANAGER_MEDIUM_BLOCK_COUNT
#define MEMORY_MANAGER_MEDIUM_BLOCK_COUNT 16
#endif

// <o> MEMORY_MANAGER_MEDIUM_BLOCK_SIZE -  Size of each memory blocks identified as 'medium' block. 
// <i>  Size of each memory blocks identified as 'medium' block. Memory block are recommended to be word-sized.

#ifndef MEMORY_MANAGER_MEDIUM_BLOCK_SIZE
#define MEMORY_MANAGER_MEDIUM_BLOCK_SIZE 256
#endif

// <o> MEMORY_MANAGER_LARGE_BLOCK_COUNT - Size of each memory blocks identified as 'large' block.  <0-255> 


#ifndef MEMORY_MANAGER_LARGE_BLOCK_COUNT
#define MEMORY_MANAGER_LARGE_BLOCK_COUNT 4
#endif

// <o> MEMORY_MANAGER_LARGE_BLOCK_SIZE -  Size of each memory blocks identified as 'large' block. 
// <i>  Size of each memory blocks identified as 'large' block. Memory block are recommended to be word-sized.

#ifndef MEMORY_MANAGER_LARGE_BLOCK_SIZE
#define MEMORY_MANAGER_LARGE_BLOCK_SIZE 512
#endif

Do you think this could have an impact?

Another question, I thought that the DFU process (at least the single bank approach) was carried out by bootloader (so the application is stopped). So what's the meaning of this macro?

// <q> NRF_DFU_IN_APP  - Specifies that this code is in the app, not the bootloader, so some settings are off-limits.
 

// <i> Enable this to disable writing to areas of the settings that are protected
// <i> by the bootlader. If this is not enabled in the app, certain settings write
// <i> operations will cause HardFaults or will be ignored. Enabling this option
// <i> also causes postvalidation to be disabled since this is meant to be done
// <i> in the bootloader. NRF_BL_DFU_ALLOW_UPDATE_FROM_APP must be enabled in the bootloader.

#ifndef NRF_DFU_IN_APP
#define NRF_DFU_IN_APP 1
#endif

And why it is called "background" DFU if the application is stopped anyway?

If the application is carrying out the DFU process is pretty easy to understand that I can't use the single bank approach (since che app can't erase itself if it is running). I need some clarifications about this.

Thanks in advance,

Alessio

RE: OTA Thread DFU: Merge SDK example with custom application

Jørgen Holmefjord — Thu, 22 Apr 2021 09:30:30 GMT

Are you using the same sdk_config.h configurations in your application as the Thread DFU client example? If you could post your full project, it would be easier to debug the application and help you find the root cause of the issue. If you do not want to share in public, I can convert the case to a private one.

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Tue, 20 Apr 2021 11:08:53 GMT

UPDATE

Also if I use the NOSD version of my application I have the crash.

The DFU process stucks at 33%

and my client starts rebooting continuosly.

This is the log of the client

As with the SD version, it tries to erase and write at 0xFF000 where there is the bootloader_setting_page and the FW crashes.

I think the new data written in 0XFF000 are wrong in some way and then the process can't go ahead.

Anyone has a tip for this? I'm out of ideas.

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Mon, 19 Apr 2021 14:06:40 GMT

UPDATE

I think I found the bug finally.

My problem is that when the board starts the update, it starts erasing flash memory where there is the Softdevice so It crashes.

I had a try with a version of my application that doesn't exploit the SD and the DFU starts normally.

I think something must be changed in the DFU example code to adapt it with a custom application that includes the softdevice.

I don't wanna update also the SD, but just the application.

Do you have any ideas which are the required steps?

I can attach the debug during the crash

Seems like there is a problem with 0x000FF000 memory slot, where there is the bootloader_settings_page

IIs it normal that the DFU application tries to erase settings memory space?

Moreover I don't know if it is normal this data when I generate the settings with

$ nrfutil settings generate --family NRF52840 --application SAMBA_Node.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 settings.hex

I think i'm using a bootloader compiled without the Softdevice options set...

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Mon, 19 Apr 2021 11:17:32 GMT

UPDATE

I found that I didn't have this macro on my custom app

while It is present in the DFU example.

I added it and now the FW crashes when I start the DFU process.

The blue mark indicates where the crash happens.

I think that macro should be in my app, so the problem is that the app crashes.

Thanks in advance,

Alessio

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Fri, 16 Apr 2021 13:53:02 GMT

[deleted]

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Thu, 15 Apr 2021 16:05:05 GMT

EDIT: Finally, with an hardcoded debug session, I found where my code failed

How can I solve "Signature failed" error?

I had the attention to use the same public key to compile bootloader and code, and the private key (from which I generated the public key) to create the app_dfu_package.zip

RE: OTA Thread DFU: Merge SDK example with custom application

AS_Kalpa — Thu, 15 Apr 2021 10:36:05 GMT

Ah ok, I thought that the public key was used also to generate the bootloader hex file.

I had a try generating a new nrf52840_xxaa_mbr.hex (bootloader) file copying my new public key in examples\dfu\dfu_public_key.c but I keep having the "prevalidation failed" error.

I'm pretty sure this error has something to do with keys.

EDIT: I put a debug message to get which is the error cause

From nrf_dfu_req_handler.h I can see:

NRF_DFU_RES_CODE_INVALID_OBJECT = 0x05, //!< Data object does not match the firmware and hardware requirements, the signature is wrong, or parsing the command failed.

So I think that:

Or it is a problem of keys and so I need some help to understand what is wrong in my approach
Or it is a problem of --sd-req 0xCA (I put 0xCA cause my app exploits s140_nrf52_7.0.1_softdevice.hex but I don't know if it is the right approach since DFU example used --sd-req 0x00)

Thanks in advance,

RE: OTA Thread DFU: Merge SDK example with custom application

Jørgen Holmefjord — Thu, 15 Apr 2021 10:13:07 GMT

By default, the DFU client example uses our public debug-key, found in examples\dfu\dfu_public_key.c. This key only works with the test-images for BLE/serial DFU, found in examples\dfu\secure_dfu_test_images. If you did not include the file containing the debug-key in your project, it should work fine to drag in the generated public key like you describe. Including both or none of the files should give compile errors, so I guess that should not be the issue here.