This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Thread Secure OTA DFU Example: Server not responding to Trigger Packet (GET)

Hello everyone,

I set up Thread Secure OTA DFU Example by using a nrf52840 DK as DFU server and a nrf52840 Dongle as DFU client. I am using nRF5 SDK for Thread and Zigbee v4.0.0.

I modified the client project and the bootloader in the example (which are for the DK) in order to be flashed on the Dongle. In particular, I simply changed the preprocessor definition from BOARD_PCA10056 to BOARD_PCA10059. I did no changes to the macros defining flash and ram start addresses and sizes, since they should already take into account the presence of mbr and bootloader. 

Then, according to this tutorial  https://infocenter.nordicsemi.com/topic/sdk_tz_v4.0.0/thread_example_dfu.html , I performed the following steps:

On the DONGLE:

> Erase: nrfjprog -f nrf52 --eraseall 

> Flash mbr: nrfjprog -f nrf52 -r --program ../../../components/softdevice/mbr/hex/mbr_nrf52_2.4.1_mbr.hex --chiperase
> Flash bootloader: nrfjprog -f nrf52 -r --program bootloader/pca10059/blank/armgcc/_build/nrf52840_xxaa_mbr.hex

> compile client application: make -C client/pca10059/blank/armgcc

> generate settins file: nrfutil settings generate --family NRF52840 --application client/pca10059/blank/armgcc/_build/nrf52840_xxaa.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 settings.hex

> merge settings with client application: mergehex -m client/pca10059/blank/armgcc/_build/nrf52840_xxaa.hex settings.hex -o dfu_client.hex

> flash client application: nrfjprog -f nrf52 -r --program dfu_client.hex --sectorerase

If I read the dongle memory, the result is the folloqing one:

Subsequently, I modified the client project by adding this line: 

bsp_board_led_on(3);

then compiled client application again and generated the new fw zip package with:

> nrfutil pkg generate --hw-version 52 --sd-req 0x00 --application-version 2 --application client/pca10059/blank/armgcc/_build/nrf52840_xxaa.hex --key-file priv.pem app_dfu_package.zip

Finally, I run this command on the DK:
> nrfutil dfu thread -f -pkg app_dfu_package.zip -p COM13 --channel 11 --panid 43981.

The result is that the dfu server remains in this condition and no firmware update occurs on the dongle. I do not see the reset of the client and the led being lighted by the new application.

 

I also set up a thread sniffer in order to understand what is happening; this is what I get:

If I power the dongle off and then power it on again, the behaviour is the following:

I have just started working with thread, but I think that the problem is that dfu server is not responding to the Trigger Packet (GET) sent by the dongle.

Is it correct? What could be the reason for this wrong behaviour?

Thank you.

Michela

Parents
  • Hi Michela,

    Sorry for the late reply. Could you run a debug session and take a look at the RTT log on the DFU client so we can get more information?

    The example runs on the nRF52840 DK and I don't see why it shouldn't run on the nRF52840 dongle once you have change the board in the preprocessor definitions in both the bootloader and the dfu client application.

    Unfortunately I am working home office and I don't have a nRF52840 dongle with the SWD header soldered to it, so I haven't been able to test the Thread DFU client example on the dongle, but I have asked a colleague to test this for me and he will try again tomorrow.

    Just to be sure, you made sure to change the preprocessor definitions flags in the Makefile right?

    Best regards,

    Marjeris

  • Hi Marjeris,

    Thank you for your reply. I have just run two debug sessions with RTT. 

    In the first case I run the debugger on the DFU client (the dongle) and then started the DFU server with nrfutil command.

    RTT log is the following:

    In the second case I just restarted the fw execution on the client (no reprogramming of the dongle) and then started DFU server: 

    These two trials were done by using the multicast DFU modality. The DFU server, in this case, blocks in this condition:

    As for the changes made to adapt the example for the dongle, here is the list:

    > client makefile

    PROJECT_NAME     := thread_secure_dfu_client_pca10059

    CFLAGS += -DBOARD_PCA10059

    > The same for the bootloader makefile

    PROJECT_NAME     := thread_secure_dfu_bootloader_secure_dfu_blank_pca10059

    CFLAGS += -DBOARD_PCA10059

    ASMFLAGS += -DBOARD_PCA10059

    ASMFLAGS += -DBOARD_PCA10059

    Is there a possibility that something is wrong with nrfutil?

    Thank you very much for your help despite the difficulties of this period.

    Best regards,

    Michela

Reply
  • Hi Marjeris,

    Thank you for your reply. I have just run two debug sessions with RTT. 

    In the first case I run the debugger on the DFU client (the dongle) and then started the DFU server with nrfutil command.

    RTT log is the following:

    In the second case I just restarted the fw execution on the client (no reprogramming of the dongle) and then started DFU server: 

    These two trials were done by using the multicast DFU modality. The DFU server, in this case, blocks in this condition:

    As for the changes made to adapt the example for the dongle, here is the list:

    > client makefile

    PROJECT_NAME     := thread_secure_dfu_client_pca10059

    CFLAGS += -DBOARD_PCA10059

    > The same for the bootloader makefile

    PROJECT_NAME     := thread_secure_dfu_bootloader_secure_dfu_blank_pca10059

    CFLAGS += -DBOARD_PCA10059

    ASMFLAGS += -DBOARD_PCA10059

    ASMFLAGS += -DBOARD_PCA10059

    Is there a possibility that something is wrong with nrfutil?

    Thank you very much for your help despite the difficulties of this period.

    Best regards,

    Michela

Children
No Data
Related