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

Help with restarting, debugging and size-limitations for DFU procedure needed

Hello,

while I already managed to solve a couple of problems regarding a proper handling of the DFU procedure in my previous topic here, there are still 3 problems that remain where I could use some help...

  1. How can I trigger a 'hard-reset' within the Nordic SDK, that behaves like using the on-/off-switch on the nRF52832 dev-board? Apparently a mere 'soft-reset' - f.ex. after a watchdog-timeout - isnt enough to get a restart in application-mode, when successfully completing the DFU procedure!

  2. How can I enable the debugging for the bootloader_secure-example, when using a gcc-toolchain? Basically something like this here, but just for a direct handling on cmd-line-basis with gcc and SDK v12.2.0! Has anyone done that before?

  3. Apparently I can only complete the DFU procedure for a pkg-file, that just includes my application (f.ex. buttonless_dfu-example), but not for a pkg-file which includes the bootloader and the softdevice due to a 'REMOTE DFU DATA SIZE EXCEEDS LIMIT'-error, even though this file is smaller then the test-files given within the dfu_send_hex-example!

I would very much appreciate any help on those issues!

Kind regards

  • Hi Ray,

    Q1: The Secure bootloader should jump to the application after the DFU procedure has been completed. Upon completion the bootloader will set the valid application flag in the bootloader settings and jump to the application. This valid application flag is checked by the bootloader everytime the device is booted up. If you've put the device in bootloader mode, but do not start any DFU process then you will stay in bootloader mode until the device is reset, unless you implement a timeout.

    I saw that you've implemented this using the WDT as I suggested in this answer. If the valid application flag is set in the bootloader settings, then a Soft-reset should result in the bootloader jumping to the application. You can check if the flag is set by reading the bootloader settings from flash using the following command:

    nrfjprog -f nrf52 --memrd 0x7F020
    

    which should be set to 1, i.e. the command should return

    0x0007F020: 00000001     
    

    Q2: I recommend using Segger's Ozone Debugger, here is the link to the download page. You need to copy the .out file from the _build folder to the same folder that contains the Makefile. Ozone should then be able to locate all the source files based on the paths in the Makefile.

    Q3: It could be an issue with the bootloader size. Can you post the nrfutil command that you used to generate the zip file ? Please also attach the generated zip file as well as the bootloader and softdevice hex files used to generate the image?

  • Thank you for your response!

    Here are some new observations/thoughts on Q1-Q3...

    Q1: (P1) Tried to understand the procedure regarding that bootloader-flag while testing with the sample-files from the dfu_send_hex-example, but unfortunately this is resulting in exactly the same behaviour as I stated in my previous topic here!

    dfu_files_sdk_test_v12.2.0.zip

    For a better understanding I documented all the steps that I took along the way:

    a. Preparations for nRF52832-DK:

    - Connected to USB (COM3)
    - Cleaned complete chip-content with 'nrfjprog --recover -f nrf52'
    -> Output:
        Recovering device. This operation might take 30s.
        Erasing user code and UICR flash areas.
    - Cleared pin-states with 'nrfjprog --pinreset -f nrf52'
    -> Output:
        Applying pin reset.
    - Checked bootloader-flag for application with 'nrfjprog --memrd 0x7F020 -f nrf52'
    -> Output:
        0x0007F020: FFFFFFFF                              |....|
    

    b. Preparations for Smartphone:

    - Re-Activated BT-Adapter on Galaxy S7
    - Removed nRF-Toolbox-app from task-manager
    - Transferred 'dfu_test_app_hrm_s132.zip'-file to 'Download'-folder on sd-card
    

    c. DFU-Procedure (used cmd-line in 'examples\dfu\ble_dfu_send_hex\test_images_update_nrf52'-folder)

    - Flashed bootloader+softdevice with 'nrfjprog --reset --program dfu_test_softdevice_bootloader_s132.hex --family NRF52 --chiperase'
    -> Output:
        Parsing hex file.
        Erasing code and UICR flash areas.
        Applying system reset.
        Checking that the area to write is not protected.
        Programing device.
        Applying system reset.
        Run.
    -> nRF52832-DK: both LED1+LED3 are 'on'
    - Checked bootloader-flag for application with 'nrfjprog --memrd 0x7F020 -f nrf52'
    -> Output:
        0x0007F020: 00000000                              |....|
    - Started nRF-Toolbox-app and selected DFU-icon
    - Selected 'dfu_test_app_hrm_s132.zip'-package in 'Download'-folder on sd-card
    -> Status: OK (32440 Bytes)
    - Selected device 'DfuTest'
    - Started upload
    -> nRF52832-DK: LED1 goes 'off' and LED2 goes 'on' during connection
    - Upload completed
    -> Status: Application has been transferred successfully
    -> nRF52832-DK: Restart upon disconnecting, resulting in both LED1+LED3 being 'on'
    - Checked bootloader-flag for application with 'nrfjprog --memrd 0x7F020 -f nrf52'
    -> Output:
        0x0007F020: 00000001                              |....|
    

    There was no change in the behaviour when repeating the dfu-procedure with the 'dfu_test_app_hrm_s132.zip'- or 'dfu_test_softdevice_bootloader_s132.zip'-file - I am always stuck in the bootloader-mode even though the flag is set correctly and I am just using official test-files!

    So either my hardware is having a problem or there is an error already within those test-files, that is causing a 'fake-check' of that flag...

    [Edit:] Just connected and flashed my custom-board through the nRF52832-DK, where both generated application-files from 'Q1: (P1)' and 'Q1: (P2)' worked directly with the proper reset-behaviour! So my guess now would be, that for some reason the nRF52832-DK isnt always handling the reset accordingly when it is programmed directly instead of being bridged for flashing a custom board! The same problem occurs with the 2nd nRF52832-DK that I got - can you confirm a similar behaviour!?

    Q1: (P2) In addition to the tests in (P1) I also tried using the combination of bootloader_secure- and buttonless_dfu-example.

    dfu_files_sdk_v12.2.0.zip

    For a better understanding I also documented the taken steps...:

    a. Preparations for nRF52832-DK:

    similar to (P1) above!
    

    b. Preparations for DFU-packages:

    - Created new private key with 'nrfutil keys generate dfu_private.pem'
    -> Output: 
        Generated private key and stored it in: dfu_private.pem
    - Converted private key to public key with 'nrfutil keys display --key pk --format code dfu_private.pem --out_file dfu_public_key.c'
    -> Output: 
        n.a.
    - Compiled bootloader_secure-example 'secure_dfu.hex'
    - Compiled buttonless_dfu-example 'buttonless_dfu.hex'
    - Created new bootloader-settings 'secure_dfu_settings.hex' with 'nrfutil settings generate --family NRF52 --application buttonless_dfu.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 secure_dfu_settings.hex'
    -> Output:
        Generated Bootloader DFU settings .hex file and stored it in: secure_dfu_settings.hex
    
        Bootloader DFU Settings:
        * File:                 secure_dfu_settings.hex
        * Family:               nRF52
        * CRC:                  0xC359D59D
        * Settings Version:     0x00000001 (1)
        * App Version:          0x00000001 (1)
        * Bootloader Version:   0x00000001 (1)
        * Bank Layout:          0x00000000
        * Current Bank:         0x00000000
        * Application Size:     0x0000D4A0 (54432 bytes)
        * Application CRC:      0x5C42E354
        * Bank0 Bank Code:      0x00000001
    - Merged bootloader-settings and bootloader with 'mergehex -m secure_dfu.hex secure_dfu_settings.hex -o secure_dfu_merged.hex'
    -> Output:
        Parsing input hex files.
        Merging files.
        Storing merged file.
    - Created new distribution-package for bootloader+softdevice with 'nrfutil pkg generate --bootloader secure_dfu_merged.hex --bootloader-version 1 --softdevice s132_nrf52_3.0.0_softdevice.hex --key-file dfu_private.pem --hw-version 52 --sd-req 0x8C dfu_softdevice_bootloader_s132_1.zip'
    -> Output:
        Zip created at dfu_softdevice_bootloader_s132_1.zip
    - Created new distribution-package for application with 'nrfutil pkg generate --application buttonless_dfu.hex --application-version 1 --key-file dfu_private.pem --hw-version 52 --sd-req 0x8C dfu_app_buttonless_s132_2.zip'
    -> Output:
        Zip created at dfu_app_buttonless_s132_2.zip
    

    c. Preparations for Smartphone:

    - Re-Activated BT-Adapter on Galaxy S7
    - Removed nRF-Toolbox-app from task-manager
    - Transferred 'dfu_app_buttonless_s132_2'-file to 'Download'-folder on sd-card
    

    d. DFU-Procedure (used cmd-line in 'examples\dfu\bootloader_secure'-folder)

    - Flashed softdevice with 'nrfjprog --reset --program s132_nrf52_3.0.0_softdevice.hex --family NRF52 --chiperase'
    -> Output:
        Parsing hex file.
        Erasing code and UICR flash areas.
        Applying system reset.
        Checking that the area to write is not protected.
        Programing device.
        Applying system reset.
        Run.
    - Checked bootloader-flag for application with 'nrfjprog --memrd 0x7F020 -f nrf52'
    -> Output:
        0x0007F020: FFFFFFFF                              |....|
    - Flashed bootloader with 'nrfjprog --reset --program secure_dfu_merged.hex --family NRF52 --sectorerase'
    -> Output:
        Parsing hex file.
        Erasing page at address 0x78000.
        Erasing page at address 0x79000.
        Erasing page at address 0x7A000.
        Erasing page at address 0x7B000.
        Erasing page at address 0x7C000.
        Erasing page at address 0x7D000.
        Erasing page at address 0x7F000.
        WARNING: A UICR write operation has been requested but UICR has not been
        WARNING: erased. Please verify that the result is correct.
        Applying system reset.
        Checking that the area to write is not protected.
        Programing device.
        Applying system reset.
        Run.
    -> nRF52832-DK: both LED1+LED3 are 'on'
    - Checked bootloader-flag for application with 'nrfjprog --memrd 0x7F020 -f nrf52'
    -> Output:
        0x0007F020: 00000001                              |....|
    - Started nRF-Toolbox-app and selected DFU-icon
    - Selected 'dfu_app_buttonless_s132_2.zip'-package in 'Download'-folder on sd-card
    -> Status: OK (55075 Bytes)
    - Selected device 'DfuTarg'
    - Started upload
    -> nRF52832-DK: LED1 goes 'off' and LED2 goes 'on' during connection
    - Upload completed
    -> Status: Application has been transferred successfully
    -> nRF52832-DK: Restart upon disconnecting, resulting in both LED1+LED3 being 'on'
    - Checked bootloader-flag for application with 'nrfjprog --memrd 0x7F020 -f nrf52'
    -> Output:
        0x0007F020: 00000001                              |....|
    

    Cant say why the bootloader-flag is already set after flashing the 'secure_dfu_merged.hex'-file, but I am sure there is an explanation for it.

    When repeating the dfu-procedure with the 'dfu_app_buttonless_s132_2.zip'-file there was no change in the behavior, but while using the 'dfu_softdevice_bootloader_s132_1.zip'-file the dfu-procedure aborted with the message 'UNKNOWN (8202)' - maybe due to a problem related to Q3!

    Q2: The idea with the Segger's Ozone Debugger is nice and I will make sure to check that out, but before that I was hoping to simply find a way to enable the NRF_LOG-messages within my gcc-toolchain!

    Q3: There definitely might be an issue with the executed procedure, since I can always observe that the created bin-file from my bootloader_secure-example is about 262 MB, while the hex- and zip-file are just 59 KB and 147 KB respectively (including the softdevice).

    Listed the entire dfu-procedure above under 'Q1: (P2)' - also included all of my generated files in the attached zip-archive!

  • Q1:Just connected and flashed my custom-board through the nRF52832-DK, where both generated application-files from 'Q1: (P1)' and 'Q1: (P2)' worked directly with the proper reset-behaviour! So my guess now would be, that for some reason the nRF52832-DK isnt always handling the reset accordingly when it is programmed directly instead of being bridged for flashing a custom board! The same problem occurs with the 2nd nRF52832-DK that I got - can you confirm a similar behaviour!?

    So flashing you custom boards with the nRF52-DK resulted in the reset-behavior, i.e. the device branches to the application. If you flash the nRF52 DK with the same firmware, you do not see the correct behavior, i.e. it stays in bootloader mode?

    Q2: Is NRF_LOG_ENABLED set to 1 in sdk_config.h?

    Q3: The hexfiles are in the intelhex format so they will be considerably smaller than the bin file.

  • Q1: Absolutely correct - normal (expected) reset behaviour on the custom board, but not on the nRF52832-DK!

    Q2: Yes I tried with NRF_LOG_ENABLED but then I get the following error-message "region `FLASH' overflowed by 4508 bytes", which is why I was hoping to get that tutorial working for my gcc-toolchain. Didnt know where to start though and what files needed to be adjusted!

    Q3: But isnt 262 MB not a bit suspicious? I included all my files in the zip-archives that are attached in my answer above, so that those can be rechecked. I would assume that there is some issue regarding the proper settings in the loader file, that I might have overlooked!

  • Q1: The bootloader test image has not been merged with any settings file generated by nrfutil and the dfu_test_app_hrm_s132.hef file. Thus, the correct behavior is that the device should stay in bootloader mode even though the application has been flashed to the device. You should see the same behavior with a custom device.

    Q2: The production bootloader example does not have the logging source files included and there is not enough space in the allocated flash section to fit the logging functionality. I recommend using the debug version, i.e. examples\dfu\bootloader_secure_ble\pca10040_debug, instead as logging is enabled by default.

    Q3: Not really, the address space of the nRF52 is huge, from 0x0000 to above 0x40002000. The bootloader example writes for instance to the UICR registers starting from 0x10001000. The area in between is filled with zeroes, a lot of zeros.

Related