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,

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

[Jørgen Holmefjord]

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?

[AS_Kalpa]

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

AS_Kalpa said:

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

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)

[AS_Kalpa]

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

[AS_Kalpa]

##### 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

[AS_Kalpa]

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,

AS

[AS_Kalpa]

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