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

[Ray Breslin]

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

[Ray Breslin]

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?

[bjorn-spockeli]

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.

[Ray Breslin]

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

[Ray Breslin]

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