sd_power_system_off(). (Advertisement LED will be lit solid, no connection is present or done.)
Hi,
I suspect the unexpected wake-up might be caused by the BOOTLOADER_BUTTON which is initialized in the bootloader code. The button is configured with sense on transitions from high to low by default. Do you see the same if remove the button configuration in bootloader main.c->buttons_init() and change nrf_dfu_button_enter_check() to always return false?
Hi,
I suspect the unexpected wake-up might be caused by the BOOTLOADER_BUTTON which is initialized in the bootloader code. The button is configured with sense on transitions from high to low by default. Do you see the same if remove the button configuration in bootloader main.c->buttons_init() and change nrf_dfu_button_enter_check() to always return false?
Hi Vidar,
Thanks for your reply. We have already disabled the BOOTLOADER_BUTTON so in our case this shouldn't be an issue. However we have good news:
We have tested to write to another flash page i.e: 0x5e instead of 0x7e. Then the device works as expected meaning it enters sleep after call to sd_power_system_off(). So writing to 0x5e was only a "qualified" guess that did the trick.
As this merely was a guess we really need to know where it is ok to write when using the secure bootloader? Is there any docs describing this, because we haven't been able to find it
Thanks for your support
Hi,
I see, I first assumed that the program entered system OFF, but woke up immediately because of bootloader pin. Page 0x7e is reserved to the MBR params page inside the bootloader and should not be accessed by the application. I would suggest storing application data right below the bootloader as our flash modules do (fds and fstorage). Typical memory layout with the bootloader is shown here: Memory layout