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

[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

[Jørgen Holmefjord]

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.

[AS_Kalpa]

Hi Jorgen,

AS_Kalpa said:

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 said before, your suggestion is exactly what I did in my application preprocessor symbols.

What about the bootloader?

AS_Kalpa said:

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.

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