[softdevice+zigbee] Problem with running BLE DFU on top of a zigbee running application

[Tu Hoang]

Hi everyone,

Currently, i am working with some zigbee devices using NRF52833 and zigbee SDK 4.1. Now, i want to use BLE DFU with it to update the firmware when needed.

There is an example of OTA zigbee server which was pretty helpful until i realized that my application can not use the same dual bank update like in the example since the size of the firmware is too big to put into 2 separate banks. So instead, it has to be a single bank update. That leads to another problem that if i use the same method with the example, the DFU is running in the application which i think is impossible to do a single bank update. So my questions are

If what i think is correct, do i have to change the bootloader to run DFU update like in the DFU example in the SDK so that when i input something it will set the GPREGRET  to 1 then reset and the bootloader will recognized the GPREGRET and turn on DFU mode like in this link infocenter.nordicsemi.com/index.jsp

If so, does using multiprotocol is still necessary because now it does not run 2 protocol at the same time. or i still have to add multiprotocol library to the firmware as well as the softdevice.

And finally, can you guys give me some hints how to add softdevice on top of a zigbee running application since softdevice blocks a lot of peripherials that i have already used like PPI, timer, FDS

Thank you and please reply soon,

Best regards,

Tu

[Edvin]

Hello Tu,

It is correct as you said, if your application is too large for dual bank, the Zigbee bootloader will not work out of the box, simply because it is designed to download the app in the background while the app is running, so you would need to fit both the old and the new application in the flash at once. 

As I see it, you have two options:

1: Use a temporary zigbee application that is smaller than your current application, which only does the job to receive the new application. Then perhaps you can fit both applications in the flash at once, and you don't need to have a BLE bootloader. Using a BLE bootloader would require you to program the softdevice (BLE stack) as well, so that would also require some flash.

2: Use a BLE bootloader. As you mentioned, you need some way to tell the device to enter DFU mode. After that you can transfer the new image, with the only flash requirement being that you need to have space for the Softdevice, the bootloader and the new application.

The advantage of the zigbee (background) DFU is that the application can download in the background, and it would only require a short reboot to swap the application. You can still use the old zigbee application while the new one is being downloaded. The draw is that the Zigbee transfer is relatively slow, compared to the BLE bootloader, which takes maximum a couple of minutes (but probably ~20-30 seconds) instead of 60 - 90 minutes. 

As for running the "multiprotocol":

You don't need to actually run multiprotocol in your application. If you don't need to run BLE in your application, all you need to do is to adjust the flash placement of your zigbee application, so that it starts after the softdevice. Then your application would be using Zigbee only, while the bootloader would use BLE only. 

If you need to use BLE (e.g. to put the device in DFU mode, if you don't want to do it another way, such as a button press or a custom Zigbee command), you can do so. For that, I would recommend you to check the multiprotocol examples from the SDK. 

Let me know what you think, and we can go from there.

Best regards,

Edvin

[Tu Hoang]

Hello Edwin,

Thank you for your detailed answer, i decided to go with the second option of BLE bootloader.

Earlier today, i tried to test the bootloader with only flashing the soft device and then the bootloader with my custom private key in, So basically, because there is no application inside, the MCU will enter DFU mode rightaway and i can flash my zip firmware package with Bluetooth through the NRF connect app from my phone. But it didn 't instead, after reset it takes like a minutes (sometimes more) to actually appear as a service on the mobile app. And even then, it is still unable to connect and the pings is very large like 15000ms. I turn on the log to see if there is any problem but it seems fine

00> <info> app: Inside main
00> 
00> <debug> app: In nrf_bootloader_init
00> 
00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
00> 
00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
00> 
00> <warning> nrf_dfu_settings: Resetting bootloader settings since neither the settings page nor the backup are valid (CRC error).
00> 
00> <debug> nrf_dfu_settings: Writing settings...
00> 
00> <debug> nrf_dfu_s<debug> nrf_dfu_settings: Using settings page.
00> 
00> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
00> 
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00> 
00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
00> 
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00> 
00> <debug> app: Enter nrf_bootloader_fw_activate
00> 
00> <info> app: No firmware to activate.
00> 
00> <info> app: Boot validation failed. No valid app to boot.
00> 
00> <debug> app: DFU mode because app is not valid.
00> 
00> <info> nrf_bootloader_wdt: WDT is not enabled
00> 
00> <debug> app: in weak nrf_dfu_init_user
00> 
00> <debug> app: timer_stop (0x20002AF4)
00> 
00> <debug> app: timer_activate (0x20002AF4)
00> 
00> <info> app: Entering DFU mode.
00> 
00> <debug> app: Initializing transports (found: 1)
00> 
00> <debug> nrf_dfu_ble: Initializing BLE DFU transport
00> 
00> <debug> nrf_dfu_ble: Setting up vector table: 0x00072000
00> 
00> <debug> nrf_dfu_ble: Enabling SoftDevice.
00> 
00> <debug> nrf_dfu_ble: Configuring BLE stack.
00> 
00> <debug> nrf_dfu_ble: Enabling the BLE stack.
00> 
00> <debug> nrf_dfu_ble: No advertising name found
00> 
00> <debug> nrf_dfu_ble: Using default advertising name
00> 
00> <debug> nrf_dfu_ble: Advertising...
00> 
00> <debug> nrf_dfu_ble: BLE DFU transport initialized.
00> 
00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_sd backend.
00> 
00> <debug> app: Enter main loop

 

I am using a custom board with nrf52833 in it and it does not have an external crytal to drive the clock. and the example bootloader i used is inside dfu/secured_bootloader/pca10100_s140_ble_debug. When flashing the softdevice and bootloader i use the "make" command from makefile. Since i did not change a thing in the code, i want to ask is there any way that i did it wrong or is it because of my custom board?

Thank you and please reply soon,

Best regards, Tu

[Edvin]

Hello Tu,

Is this log from before or after you tried to transfer the application to the nRF using the phone?

What does it say when you try to transfer using the phone?

You say that your nRF52833 doesn't have an external LFXTAL. Did you apply this into the applications sdk_config.h file? And did you apply it to the bootloader's sdk_config.h file?

The definitions that you should look for and change are the following:

#define NRF_SDH_CLOCK_LF_SRC 0
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#define NRF_SDH_CLOCK_LF_ACCURACY 1

Please note the one with the accuracy. You must set this to 1 (500ppm).

If that doesn't work, can you please let me know what nRF Connect for iOS/Android says when you try to upload the new image? What does the log from the bootloader say? And what command did you use to generate the image that you are transferring?

Please note that the *_debug bootloader project has it's own sdk_config.h file. It is not the same as the non *_debug version.

Best regards,

Edvin

[Tu Hoang]

Hello Edwin,

Thank you for your answer,

I change the marco according to your recommendation and it works fine now may be that is the root of my problem. I am now able to run DFU and connect to my board and upload the new firmware. But there is another problem: after the transfer to 100% the device restart but not boot in to the application and it given out this log

<debug> nrf_dfu_ble: Shutting down BLE transport.

<debug> nrf_dfu_ble: Disconnecting.

<info> app: Inside main

<debug> app: In nrf_bootloader_init

<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...

<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.

<debug> nrf_dfu_settings: Using settings page.

<debug> nrf_dfu_settings: Copying forbidden parts from backup page.

<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.

<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.

<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.

<debug> app: Enter nrf_bootloader_fw_activate

<debug> app: Valid App

<debug> app: Enter nrf_dfu_app_continue

<debug> app: No copy needed

<debug> app: Setting app as valid

<debug> nrf_dfu_settings: Writing settings...

<debug> nrf_dfu_settings: Erasing old settings at: 0x0007F000

<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0007F000, len=1 pages), queue usage: 0

<debug> nrf_dfu_flash: Flash erase success: addr=0x0007F000, pending 0

<info> app: Inside main

<debug> app: In nrf_bootloader_init

<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...

<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.

<debug> nrf_dfu_settings: Using settings page.

<debug> nrf_dfu_settings: Copying forbidden parts from backup page.

<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.

<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.

<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.

<debug> app: Enter nrf_bootloader_fw_activate

<info> app: No firmware to activate.

<debug> app: App is valid

<debug> nrf_dfu_settings_svci: Erasing settings page additional data.

it looks like it reset a couple time and does not go in to the application, i do not know why but i think that i have created the zip package wrong, so i want to ask if there is any extra steps for create a zigbee firmware package for DFU because i can see that there is some argument for relating to zigbee in nrfutil pkg generate --help. My memory setting for the app in .ld file is like this

MEMORY
{
  FLASH (rx) : ORIGIN = 0x27000, LENGTH = 0x50000
  RAM (rwx) :  ORIGIN = 0x20000008, LENGTH = 0x1fff8
  uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4
  mbr_params_page (r) : ORIGIN = 0x0007E000, LENGTH = 0x1000
  bootloader_settings_page (r) : ORIGIN = 0x0007F000, LENGTH = 0x1000
  uicr_mbr_params_page (r) : ORIGIN = 0x10001018, LENGTH = 0x4
}

the bootloader memory  is still the same as the example of pca10100_s140_ble_debug, the command i use to create the Zip file is 

nrfutil pkg generate --hw-version 52 --application-version 2 --application _build/nrf52833_xxaa.hex --sd-req 0xCA --key-file app_private_key.pem app_dfu_package.zip

and i have another problem that bacause i  do not use softdevice in the main application, do i really have to include --sd-req in this command, also , my firmware is flash from 0x27000 to 0x6D000 in the memory

Please give me some hints for this,

Best regards,

Tu

[Edvin]

Tu Hoang said:

because i can see that there is some argument for relating to zigbee in nrfutil pkg generate --help

 Yes it is, but if you are using the BLE bootloader, you should not use --zigbee. For the bootloader, this looks like a completely normal BLE application. It doesn't need to know about the zigbee stack at all.

 

Tu Hoang said:

and i have another problem that bacause i  do not use softdevice in the main application, do i really have to include --sd-req in this command, also , my firmware is flash from 0x27000 to 0x6D000 in the memory

 This applies here as well. Your bootloader is not aware of the zigbee application, so you should use the --sd-req as if it was a BLE application. This is to make sure that the bootloader is not bricked in the future, and to tell the bootloader that it shouldn't delete the softdevice when the application is received.

It looks like the bootloader is accepting the application, so I am not quite sure why it is not working. Just to make sure, you are using the bootloader found in SDKv4.1.0\examples\dfu\secure_bootloader\pca10056_s140_ble_debug, right?

Perhaps you can try to use the attached .bat script from the folder location:

SDKv4.1.0\examples\dfu\secure_bootloader\pca10056_s140_ble_debug\armgcc\test.bat. (adjust it to use your own DK's serial numbers:

Fullscreen test.bat Download

make -j9 
make -j9 -C ..\..\..\..\ble_peripheral\ble_app_buttonless_dfu\pca10056\s140\armgcc 
mkdir files

set TARGET_SNR=683963588
set CONNECTIVITY_SNR=682396787

del files\buttonless.hex
del files\bl_settings.hex
del files\dfu_image_2.zip
copy ..\..\..\..\ble_peripheral\ble_app_buttonless_dfu\pca10056\s140\armgcc\_build\nrf52840_xxaa.hex files\buttonless.hex 
nrfutil settings generate --family NRF52840 --application files\buttonless.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 --key-file ..\..\..\private.pem files\bl_settings.hex 
nrfutil pkg generate --application files\buttonless.hex --application-version 2 --sd-req 0xCA --hw-version 52 --key-file ..\..\..\private.pem files\dfu_image_2.zip 
nrfutil pkg generate --application files\buttonless.hex --application-version 3 --sd-req 0xCA --hw-version 52 --key-file ..\..\..\private.pem files\dfu_image_3.zip 

nrfjprog -e --snr %TARGET_SNR%
nrfjprog --program _build\nrf52840_xxaa_s140.hex --verify --snr %TARGET_SNR%
nrfjprog --program ..\..\..\..\..\components\softdevice\s140\hex\s140_nrf52_7.0.1_softdevice.hex --verify --snr %TARGET_SNR%
nrfjprog --program files\buttonless.hex --verify --snr %TARGET_SNR%
nrfjprog --program files\bl_settings.hex --verify --snr %TARGET_SNR%
nrfjprog --reset --snr %TARGET_SNR%


nrfutil dfu ble -pkg files\dfu_image_2.zip -ic NRF52 -snr %CONNECTIVITY_SNR% -n "Nordic_Buttonless"
TIMEOUT 10
nrfutil dfu ble -pkg files\dfu_image_3.zip -ic NRF52 -snr %CONNECTIVITY_SNR% -n "Nordic_Buttonless"

What it does is simply running a DFU to a BLE application. Just to check whether the issue is with the bootloader or the application. 

Have you tried setting a breakpoint in the application to see if it is hit? Perhaps the application crashes before anything is logged. 

You can also see how the script generates and programs the bootloader settings. Try to apply the same with your application, and see if it boots up.

Best regards,

Edvin

[Edvin]

FYI: When you set the status to Verified Answer, it no longer pops up in my queue if you write anything more in this ticket. If you need to, please either create a new ticket, or send me a PM here on DevZone to let me know about the update.