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

edit retag close delete

Sort by » oldest newest most voted

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.

more

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... :)

( 2017-04-24 16:36:14 +0100 )editconvert to answer

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 :)

( 2017-04-24 16:39:34 +0100 )editconvert to answer

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?

more

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


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
-> Status: OK (32440 Bytes)
- Selected device 'DfuTest'
-> nRF52832-DK: LED1 goes 'off' and LED2 goes 'on' during connection
-> 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 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

* File:                 secure_dfu_settings.hex
* Family:               nRF52
* CRC:                  0xC359D59D
* Settings Version:     0x00000001 (1)
* App 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:
- 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


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.
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
-> Status: OK (55075 Bytes)
- Selected device 'DfuTarg'
-> nRF52832-DK: LED1 goes 'off' and LED2 goes 'on' during connection
-> 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!

more

Q1:Just connected and flashed my custom-board through the nRF52832-DK, where both generatedapplication-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 accordinglywhen 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.

( 2017-04-24 10:06:11 +0100 )editconvert to answer

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!

( 2017-04-24 13:36:43 +0100 )editconvert to answer

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.

( 2017-04-24 15:28:00 +0100 )editconvert to answer

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?

( 2017-04-24 15:58:58 +0100 )editconvert to answer

[hide preview]

Recent blog posts

• Introduce smart motion controller - ELIO

Posted 2017-12-12 05:09:05 by caram5555
• The world's smallest breakout board compatible BTLE module: Automate your curtains for less than \$90 with BluChip!

Posted 2017-12-07 09:10:36 by Jeevan Anga
• Join Jumper's free beta for a Virtual nRF52832 device to streamline your R&D process

Posted 2017-11-27 12:53:04 by Yaniv Nis

Posted 2017-11-27 11:08:04 by Mugelan
• Job Offer: nRF / Embedded Developer in Stuttgart, Germany

Posted 2017-11-20 11:46:20 by Marius Heil

Recent questions

Posted 2017-12-12 10:03:07 by roger.k
• system_info.h: No such file or directory what can i do?

Posted 2017-12-12 09:52:43 by AMER

Posted 2017-12-12 09:17:44 by Aurabindo
• nRF51422 Current Consumption

Posted 2017-12-12 08:14:15 by Dilip
• uarte dma switch moment

Posted 2017-12-12 08:07:14 by Stayhungry