System hangs switching from Application to Bootloader

[Locky]

I've implemented a Application and Bootloader.  I have the Bootloader set to Buttonless.  However when I try to transition from the Application to Bootloader via:

/* Sets Flags for DFU Triggering */
uint8_t reg_val = nrf_power_gpregret_get();
reg_val = reg_val | 0xB1; /* Set bit 1 to triger DFU */
nrf_power_gpregret_set(reg_val);

/* Reset Device */
sd_nvic_SystemReset();

The system simply seems to hang.  On Power reset, it reverts back to the Application.  If I program the SD and bootloader I can successfully upload an Application image.  However when I tried to trigger a DFU again from the App, it again hangs after the reset.  I can't see what I've done wrong.  Here are my linker file settings:

Application:

MEMORY
{
FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x2ED08
RAM (rwx) : ORIGIN = 0x200059b8, LENGTH = 0xa648
CUSTOM_MEM (rx) : ORIGIN = 0x55000, LENGTH = 0x0C300
}

Bootloader

MEMORY
{
FLASH (rx) : ORIGIN = 0x78000, LENGTH = 0x6000
RAM (rwx) : ORIGIN = 0x200057b8, LENGTH = 0xa848
mbr_params_page (r) : ORIGIN = 0x0007E000, LENGTH = 0x1000
bootloader_settings_page (r) : ORIGIN = 0x0007F000, LENGTH = 0x1000
dfu(r) : ORIGIN = 0x10001018, LENGTH = 0x4
uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4
}

As you may note I can set aside a section of Flash in the Application for some custom code I use to program external IC's.  I'm using SD 132 v 6.1.1

[Edvin]

Hello,

Can you please try to use the bootloader project found in pca10040_ble_debug, and monitor the RTT log when you try to enter the bootloader?

The log from the bootloader may say something about why it stops.

Either, the bootloader is not started properly, because of a bug there, or if the register is not set correctly, or it restarts the application, but this crashes, causing you to have an infinite app_error->reboot loop.

Did you do any changes in the bootloader project?

Have you checked out the ble_app_buttonless_dfu example in the SDK, which has a separate BLE service to put the device in DFU mode? You can see there how it tells the bootloader to stay in DFU mode on the next reset.

Perhaps you don't wait long enough between the nrf_power_gpregret_set() and sd_nvic_SystemReset()? I suspect this is the case if the implementation is like you describe in the snippet, with nothing else in between.

Try to add a few ms of delay before you reset, so that the register has time to be written before you reset.

BR,

Edvin

[Locky]

When I program the softdevice and my bootloader or the example bootlaoder everything runs fine and the Application updates and runs.  But when I try and trigger a DFU update from the Application,  everything freezes again after the sd_nvic_SystemReset().  I added a delay after setting the retention register (though I've never had to do this before) but the effect is the same.  

I suspect there are two possible issues.  Either for some reason the MBR doesn't contain the right vector to jump to the bootloader, or somehow the bootloader gets corrupts upon Application update.

[Edvin]

Edvin said:

Can you please try to use the bootloader project found in pca10040_ble_debug, and monitor the RTT log when you try to enter the bootloader?

[Locky]

Hi Edvin,

As I previously mentioned, I did this and it works the same as my bootloader.  Successfully updates the Application.  But when I triigger a new update from the Application via

/* Sets Flags for DFU Triggering */
uint8_t reg_val = nrf_power_gpregret_get();
reg_val = reg_val | 0xB1; /* Set bit 1 to triger DFU */

vTaskDelay(10);
nrf_power_gpregret_set(reg_val);

The system hangs instead of starting the bootloader.  No led toggles, no Advertising.  Upon power reset the Application starts

[Locky]

Found the issue. The Flash memory section which contains the MDR and Settings seems to be corrupted.  Not entire unexpected as the PCA10040 I'm using has be developed on for years..  I verified that some sections of the Flash for the MBR and Bootsettings were not saving properly.  Caused issued with system resets but not power resets oddly enough.