RE: GPREGRET/GPREGRET2 are bitmask registers?

Tony Garland — Sat, 16 Jul 2016 00:02:08 GMT

Here's something I just submitted as a support case (wasn't able to easily find where SDK suggestions/defects were to be officially submitted).

this is to alert you to a liability in the example bootloader code in the SDK. Specifically, the bootloader_start() function within

nRF5_SDK_11.0.0_89a8197.zip/libraries/bootloader/dfu/dfu_app_handler.c has the following code (line 140):

err_code = sd_power_gpregret_set(BOOTLOADER_DFU_START);

When the bootloader gains control from bootloader_start(), it checks this value to determine whether the application initiated a DFU operation. If this value does not match, it assumes a boot from restart, initializes the soft device, and will wind up immediately calling back into the application. Whereupon the application reinitializes the soft device as if a reset had occurred and a hard fault results.

Here's the problem: if any bit happens to be set in the GPREGRET register which is outside of the bit values of the BOOTLOADER_DFU_START value, then the above call will NOT result in GPREGRET having a value of BOOTLOADER_DFU_START--it will just set those bits along with whatever other bit(s) happen to already be set.

This was happening in our application--where we use GPREGRET for other purposes prior to initiating switch to DFU from the app. The fix is pretty simple and much more robust:

// Clear GPREGRET and set our exact DFU value.

err_code = sd_power_gpregret_clr(0xffffffff);

APP_ERROR_CHECK(err_code);

err_code = sd_power_gpregret_set(BOOTLOADER_DFU_START);

APP_ERROR_CHECK(err_code);

Perhaps it would be a good change to make in an upcoming SDK release as it would insulate the app-initiated DFU process from this potential glitch.