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

Secure Buttonless DFU Problem on nRF52832 Soft Device 112

Hello

I am facing problem from many days on buttonless DFU.

Whoever from Nordic approaches kindly give a customized solution rather than other links. I have almost gone through all the links with none exactly matching my issue. I will be really thankful.

I am trying to perform Buttonless DFU on nRF52832 512 kB version on nRF DK. I am using SDK 112 v7 (the latest one) and latest versions of nRF util, etc.. as well. Although I am using SDK 16.

My first act was to convert my application from s132 to S112 on nRF52832 a few months ago as I was using default ble_app_blinky as my base. A kind person from nordic helped me on the issue since the memory mapping on s112 pca10040 example is that of nRF52810

Now for DFU, I am supposed to convert the bootloader s112 example on nRF52810 to nRF52832 by editing the project file for library and memory mapping right?

I used the following links:

1) https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.3.0%2Flib_bootloader.html

2) https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader#h61sjziauupw1j397q9s9ldr01q4j6d5

3) https://devzone.nordicsemi.com/f/nordic-q-a/41386/guide-to-allocate-the-amount-of-ram-rom-i-need

and my project application  + BL + setting + SD oombined well using merge hex. It  went into DFU mode on start up and I started OTA 

OTA package is received successfully and after 100% OTA the DK rebooted and nRF log said bootloader not found:

My guess is something is wrong in my conversions as I am trying to convert from s112 nRF52810 examples to nrf 52832 the following projects:

1) Bootloader S112 example

2) I OTA ble_app_blinky s112 example and change it's memory mapping and nrf52832 libraries as we have to keep the same soft device in OTA

Please note from above screenshot that my OTA is fully complete (100%)

I am using the following memory mapping:

1) Bootloader example: nrf52832 s112

linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x80000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x10000;FLASH_START=0x78000;FLASH_SIZE=0x6000;RAM_START=0x20005968;RAM_SIZE=0xa698"

linker_section_placements_segments="FLASH RX 0x0 0x80000;RAM RWX 0x20000000 0x10000;uicr_bootloader_start_address RX 0x10001014 0x4;uicr_mbr_params_page RX 0x10001018 0x4;mbr_params_page RX 0x0007E000 0x1000;bootloader_settings_page RX 0x0007F000 0x1000"

2) Base Application FW - nrf52832 s112

linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x80000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x10000;FLASH_START=0x26000;FLASH_SIZE=0x5a000;RAM_START=0x200022f0;RAM_SIZE=0xdd10"


linker_section_placements_segments="FLASH RX 0x0 0x80000;RAM RWX 0x20000000 0x10000"

3) The OTA package - S112 nRF52832

linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x80000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x10000;FLASH_START=0x26000;FLASH_SIZE=0x5a000;RAM_START=0x20001ae0;RAM_SIZE=0x4520"

linker_section_placements_segments="FLASH RX 0x0 0x80000;RAM RWX 0x20000000 0x10000"

Here are my nrfutil commands -

1) Bootloader settings and hex merges

BOOTLOADER SETTINGS
nrfutil settings generate --family NRF52 --application E_MCB_Project.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 bootloader_settings.hex


nrfutil settings generate --family NRF52 --application E_MCB_Project.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 --app-boot-validation VALIDATE_GENERATED_CRC --softdevice s112_sd.hex --sd-boot-validation VALIDATE_GENERATED_CRC bootloader_settings.hex


SETTING AND BOOTLOADER MERGE
mergehex -m secure_bootloader.hex bootloader_settings.hex -o bootloaderAndSettings.hex

PACKAGE HEX FROM ABOVE
mergehex -m bootloaderAndSettings.hex s112_sd.hex -o random.hex

PACKAGE HEX FROM ABOVE 2
mergehex -m random.hex E_MCB_Project.hex -o package_EMCB.hex

Here are commands I used for OTA package

echo "## Creating a FW.zip package that can be used to update the FW on the DK"


nrfutil pkg generate --application blinky_112_2.hex --application-version 61 --application-version-string "1.0.61" --hw-version 52 --sd-req 0xCD --sd-id 0xCD --softdevice s112_sd.hex --key-file private.pem fw81_MCB.zip


echo.

sd_112. hex is default  soft devicce 112 I just renamed it rest is self explanatory.

I have provided complete details and I need help on this. Please provide a customized solution and please dont divert me to other links. Its not a huge issue the OTA happens perfectly  but after reboot it cannot find the bootloader

I am assuming its something withbootloader settings or bootloader memory mapping

Regards

Ali

Parents
  • Hello,

    Try to use only --application-version 61. You are not supposed to use both --application-version and --application-version-string in the same packet. So try to use just one of them.

    You can't update a major softdevice version without updating the bootloader. You should actually probably always update the bootloader when you update the softdevice, so that you are 100% sure that you have a working pair. The bootloader depends on a compatible softdevice to be able to advertise and receive packets for the new application.

    Does it work to update the application only? (to another application using the same version of the softdevice)

    When you try to do SD+BL+APP, what was the old present softdevice version, what is the new one, and what command do you use to generate the DFU image?

    BR,

    Edvin

  • Hello Edvin

    I will try without application version string.

    Oh so you mean to say we cant do APP + SD we need to do APP + SD + BL always. That makes sense why it wasn't working with APP + SD

    Yes it does work when I OTA application only; and yes the soft device versions were same of both - S112

    I wanted to know if the steps were right. I changed linker addresses according to S112 on nRF52832 using info center links in the post. Please tell me if this was corrrect.

    On SD + BL + APP it seemed to send the TWO zip packages around 2-3 times (It said uploading 1 0f 2 and then 2 of 2) and then repeat.

    The old soft device was S112 and new one was S132 (OTA package). It worked on S132 SD + BL + APP with repetitions like I said but it didn't work at all with S112 in OTA package.

    The command was this:

    nrfutil pkg generate --application E_MCB_Project_CRC.hex --application-version 61 --application-version-string "1.0.61" --bootloader secure_bootloader.hex --bootloader-version 1 --hw-version 52 --sd-req 0xCD --sd-id 0xCD --softdevice s112_132.hex --key-file private.pem fw87_BL_SD_APP.zip

    secure_bootloader. hex is s112 project with all changes and details in original post please and the soft device is S132 default hex file.

    The code on the DK had S112

    Ali

  • Yes Hung of course I can debug. By trivial I meant if I am debugging the bootloader as an application separately means I erase the flash and debug it right?

    If Im debugging it separately then how can I be sure CRC went wrong when debugger tried to boot application after OTA right?

    Kindly answer this question for me.

    Meanwhile I will debug and share findings with you

    Ali

  • Hi Hung

    I tried what you said. Took me hours but I could not debug the debug version of secure bootloader. Gave me all sorts of errors on optimization and nrf_log_enabled

    However I commented this line in bootloader to create full package via merge hex and it worked fine:

    if (s_dfu_settings.bank_0.bank_code != NRF_DFU_BANK_VALID_APP)
    {
    NRF_LOG_INFO("Boot validation failed. No valid app to boot.");
    return false;
    }

    But after 2 OTAs same problem started happening. I could see dual applications in nRF connect memory map!

    I think there is CRC problem based on the line I shared with you.

    I tried to generate boootloader settings without validation then it should have worked right?

    nrfutil settings generate --family NRF52 --application E_MCB_Project.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 bootloader_settings.hex

    I used above line

    Same problem persisted if I left the validation part uncommented in bootloader project.

    I think the issue is pinpoint now. Can you please guide me from here please?

    I also have 2 questions:

    1) What does the validation commands during bootoader settings do. because settings without validation gave me the same error?

    2) When is CRC calculated and how? This question is bassically to solve the main problem

    Really thanks again for your help Hung. I hope you can help more and we can solve this problem allthe way!

    Ali

  • Hi Ali, 
    What I suggested to test the bootloader in debug mode and step into the code is to debug this issue:
    "After using merge hex to compile settings and bootloader and application and soft device; I noticed advertisement on nRF connect as DFU targ and not buttonless DFU. "

    You don't need to do DFU update to test this, just flash the hex files and then step in to the code to check why

     if (s_dfu_settings.bank_0.bank_code != NRF_DFU_BANK_VALID_APP)

    return false. 

    The bootloader setting supposed to mark the application as valid, as well as CRC value. Unless you have generated wrong bootloader setting,make sure the address of the bootloader setting is at page 0x7F000 . It should be by default but I don't know, please double check. 

    But this is only one of the issues, per my understanding. Do we still have other issue with DFU update after you move the application to the correct place ?

  • Hi Hung

    There is no other issue. And I get it why you asked me to debug. It's just that I spend too much time on nrf debug making its optimization zero and everthing. Instead I just commented the first line as I shared and looks like that was the error

    Because normally when i merged all files and flashed them it always took me to DFU targ and now it's taking me to Application directly!

    So all that is left now to see why its working when I comment that line? Also my settings are on that addresss 0x7F000.

    Now that issue is identified what do I do?? Debug more?
    In that case I wasnt able to debug the debug version of secure bootloader. It gave me many errors once I removed optimization.

    or If you know exactly why I got the CRC wrong. Perhaps my bootloader setting generation syntax is wrong?, then please tell me.

    Ali

  • Hi Hung

    I managed to debug it. Turns out to customize debug version for nrf52832 I had to convert it from scratch not just copy paste the non debug version project settings.

    Here is the error log

    00> <info> app: Inside main
    00> <debug> app: In nrf_bootloader_init
    00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
    00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    00> <warning> nrf_dfu_settings: Resetting bootloader settings since neither the settings page nor the backup are valid (CRC error).
    00> <debug> nrf_dfu_settings: Writing settings...
    00> <debug> nrf_dfu_settings: Erasing old settings at: 0x0002F000
    00> <debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0002F000, lending 0
    00> ding 0
    00> <info> nrf_dfu_settings: Backing up settings page to address 0x2E000.
    00> <debug> nrf_dfu_settings: Writing settings...
    00> <debug> nrf_dfu_settings: Erasing old settings at: 0x0002E000
    00> <debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0002E000, len=1 pages), queue usage: 1
    00> <debug> nrf_dfu_flash: Flash erase success: addr=0x0002E000, pending 0
    00> <debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0002E000, src=0x20007ACC, len=896 bytes), queue usage: 1
    00> ding 0
    00> <debug> app: Enter nrf_bootloader_fw_activate

    Please note that I fully erased the device via nRF Connect and build and run the debug version project from SES.

    Once again thanks for your help Hung but some quick help is needed from you on this matter. This issue has been going for many days at work, hope you understand

    Ali

Reply
  • Hi Hung

    I managed to debug it. Turns out to customize debug version for nrf52832 I had to convert it from scratch not just copy paste the non debug version project settings.

    Here is the error log

    00> <info> app: Inside main
    00> <debug> app: In nrf_bootloader_init
    00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
    00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    00> <warning> nrf_dfu_settings: Resetting bootloader settings since neither the settings page nor the backup are valid (CRC error).
    00> <debug> nrf_dfu_settings: Writing settings...
    00> <debug> nrf_dfu_settings: Erasing old settings at: 0x0002F000
    00> <debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0002F000, lending 0
    00> ding 0
    00> <info> nrf_dfu_settings: Backing up settings page to address 0x2E000.
    00> <debug> nrf_dfu_settings: Writing settings...
    00> <debug> nrf_dfu_settings: Erasing old settings at: 0x0002E000
    00> <debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0002E000, len=1 pages), queue usage: 1
    00> <debug> nrf_dfu_flash: Flash erase success: addr=0x0002E000, pending 0
    00> <debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0002E000, src=0x20007ACC, len=896 bytes), queue usage: 1
    00> ding 0
    00> <debug> app: Enter nrf_bootloader_fw_activate

    Please note that I fully erased the device via nRF Connect and build and run the debug version project from SES.

    Once again thanks for your help Hung but some quick help is needed from you on this matter. This issue has been going for many days at work, hope you understand

    Ali

Children
  • Hi Hung

    The above message was simply running bootloader application (obviously problem is with bootloader)

    Below are prints when i merge settings,SD, App and bootloader combined.

    As expected device goes into DFU mode straight away:

    00> <info> app: Inside main
    00> <debug> app: In nrf_bootloader_init
    00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
    00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    00> <debug> nrf_dfu_settings: Using settings page.
    00> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
    00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
    00> <info> nrf_dfu_settings: Backing up settings page to address 0x2E000.
    00> <info> app: Entering DFU mode.

    One thing I see is that in both prints it is finding bootloader settings in 2E000 even when I have placed in 7E000 accordingly. Perhaps that issue. Your help is required Hung.

    Please note that my boootloader memory map is:

    linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x80000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x10000;FLASH_START=0x72000;FLASH_SIZE=0xc000;RAM_START=0x20005968;RAM_SIZE=0xa698"

    linker_section_placements_segments="FLASH RX 0x0 0x80000;RAM RWX 0x20000000 0x10000;uicr_bootloader_start_address RX 0x10001014 0x4;uicr_mbr_params_page RX 0x10001018 0x4;mbr_params_page RX 0x0007E000 0x1000;bootloader_settings_page RX 0x0007F000 0x1000"

    Thanks in advance

    Ali

  • Hi Ali,

    AliMahmood123 said:
    One thing I see is that in both prints it is finding bootloader settings in 2E000 even when I have placed in 7E000 accordingly. Perhaps that issue.

     The settings address is wrong as you say, but did you mean to write 0x2F000? That's the default BL settings address if you build the project for the nRF52810 (see nrf_dfu_types.h).

    And with regards to porting, it's easier to take an existing nRF52832+s132 and change out the Softdevice than it is to take a 52810+s132 project and port it to nrf52832.  I just did that for 'pca10040_s132_ble_debug' configuration in SDK 16.0.0, see attached below. Can you give this project a try?

    pca10040_s112_ble_debug.zip

  • Hi Vidar

    I like this Idea, I shall try it and update you soon. I hope you read the OP and all the prevailing discussions.

    Your idea was great Vidar, but can I get back to Hung with this if this doesnt work? He knows complete history would save you a  lot of trouble?

    Ali

  • Hi Vidar. I tried your project's hex file.I merged it with my application and ran it. Same result as before.

    I really need guidance here. Why would it go to 2E000 address when I set address as 7E000. This issue is being delayed at work as well.

    Ali

  • Hi Ali,

    The bootloader also uses the BOOTLOADER_SETTINGS_ADDRESS and NRF_MBR_PARAMS_PAGE_ADDRESS symbols defined in nrf_dfu_types.h, and the fact that it says the settings page is *backed* up to 0x2E000 indicates that you are still building the project for NRF52810_XXAA.

    Attached below is the bootloader project I configured earlier and a version of the ble_app_blinky example thatI have modified to include the buttonless DFU mechanism. Please try DFU with these. Test image is included so you don't have to generate the zip file.

    nRF5_SDK16.0.0_examples.zip

Related