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

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

Ray Breslin — Mon, 24 Apr 2017 14:39:34 GMT

Apparently that solved the issue for both Q1 and Q3 - wasnt able to reproduce the "non-reset"-behaviour again even for the nRF52832-DK!

Just to be sure I would want to leave the topic still open for 1 more week or so, in order to run more tests - but looks good atm! Thanks again for your support :)

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

Ray Breslin — Mon, 24 Apr 2017 14:36:14 GMT

Q1: Yes you are correct, I am observing this behaviour only after doing an OTA-DFU for the application. Thought I described that above, but I might have gotten a bit lost while providing this many informations!

Q3: Oh ok - thanks for that advice! Will try that asap... :)

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

bjorn-spockeli — Mon, 24 Apr 2017 14:14:36 GMT

Q1: Sorry, I though you meant flashing the SoftDevice and bootloader and application test hex files. If you reset after that you will stay in bootloader mode. You are referring to the reset after an application OTA DFU has been performed right?

Q3: I think I spotted the error: You are creating a bootloader image using the merged bootloader+settings file, created using the following command

mergehex -m secure_dfu.hex secure_dfu_settings.hex -o secure_dfu_merged.hex

The settings file should only be merged with the bootloader hex when you're flashing the SoftDevice, Bootloader and the application using a programmer. The settings file must be omitted when you create OTA DFU images.

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

Ray Breslin — Mon, 24 Apr 2017 13:58:58 GMT

Q1: I dont realy get that, since the test-files show your described behaviour only with the nRF52832-DK, but work directly out-of-the-box for the custom-board. Same goes for the bootloader_secure- and buttonless_dfu-files! After running quite a number of additional tests, I do sometimes get the expected reset even on the nRF52832-DK - but its not only in 2-5% of all attempts and not being reproducable. Is there any error in the executed prodecure, which I posted above? Do the bootloader-settings need to be merged in more then 1 file?

Q2: Ok that sounds like a good idea - I will try that for sure!

Q3: Hmmmm... you happen to have any other idea then, why I am facing the "UNKNOWN (8202)"-error? Is it maybe a masked "REMOTE DFU DATA SIZE EXCEEDS LIMIT"-error instead due to not using the correct memory-layouting and address ranges?

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

bjorn-spockeli — Mon, 24 Apr 2017 13:28:00 GMT

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.

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

Ray Breslin — Mon, 24 Apr 2017 11:36:43 GMT

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!

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

bjorn-spockeli — Mon, 24 Apr 2017 08:06:11 GMT

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.

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

Ray Breslin — Thu, 20 Apr 2017 13:48:37 GMT

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!

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

bjorn-spockeli — Wed, 19 Apr 2017 09:35:42 GMT

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?