OTA Thread DFU: Merge SDK example with custom application

[AS_Kalpa]

Hi all!

I'm able to fully test the SDK example https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_tz_v3.2.0%2Fthread_example_dfu.html and it works pretty well.

Now, the next step is the integration of this OTA DFU over Thread example in my custom application (that already exploits Thread and MQTT-SN protocol).

I haven't found a tutorial that explains step-by-step this kind of operation. 

Basically I need some help to integrate the DFU client with the user application. I think the key point is the IoT SDK CoAP library that implement a DFU algorithm that should run concurrently to the user application, but I'm a bit confused about merging process.

Thanks in advance,

Alessio

[AS_Kalpa]

I think I need some clarifications about flashing different FW components.

In order to have the OTA DFU example working, I have to flash:

• mbr_nrf52_2.4.1_mbr.hex (MBR)

• nrf52840_xxaa_mbr.hex (BOOTLOADER)

• dfu_client.hex (EXAMPLE HEX)

In order to have my application working, I have to flash:

• s140_nrf52_7.0.1_softdevice.hex (SOFTDEVICE)

• my_app.hex (APPLICATION HEX)

At the moment, I have merged the two application codes and, let's say, I have the  

my_app_DFU.hex

I have tried to flash all the components:

1. mbr_nrf52_2.4.1_mbr.hex (MBR)

2. nrf52840_xxaa_mbr (BOOTLOADER)

3. s140_nrf52_7.0.1_softdevice.hex (SOFTDEVICE)

4. my_app_DFU.hex (APPLICATION+DFU HEX)

I received back this when I flash the SD

and this when I flash the application

Moreover, the dongle is stucked with the green led lit up.

Maybe I am supposed to do some mergehex operations?

Thanks,

Alessio 

 

[Jørgen Holmefjord]

Hi,

You do not need to flash both the MBR and Softdevice HEX-files. The MBR is merged into the softdevice, and you will find that if you do a compare, the first page (0x0 - 0x1000) will be identical.

The Bootloader needs information about the application in order to verify that it is a valid application. This means that you either needs to generate the settings using nrfutil, or create a DFU packet of the application and "flash" it using the DFU process. 

I recommend that you follow the instructions in the Testing section of the Thread Secure OTA DFU Example, especially steps 3.c-d.

Best regards,
Jørgen 

[AS_Kalpa]

Hi Jorgen,

Jørgen Holmefjord said:

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.

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. 

[AS_Kalpa]

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

[Jørgen Holmefjord]

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

[AS_Kalpa]

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

[AS_Kalpa]

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

Finally I have the multiprotocol version working.

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

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

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.

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