For anyone visiting this thread's reference, here's how I accomplished an mbed based bootloader that forwards execution to a mbed main application on the nRF52832:

As mentioned in Russ's post, there's a line in mbed-os/platform/mbed_application.c called during "mbed_start_application" that relocates the VTOR pointer. This breaks compatibility with the Nordic MBR and softdevice (which should always be forwarded interrupts when in use).

You need to conditionalize this line based on your target or comment it out. I have custom targets based on the NRF52_DK and put compiler directives around it as shown below:

static void powerdown_scb(uint32_t vtor)
{
    int i;

    // SCB->CPUID   - Read only CPU ID register
    SCB->ICSR = SCB_ICSR_PENDSVCLR_Msk | SCB_ICSR_PENDSTCLR_Msk;

    /***** MODIFICATION ******/
    // Prevent the vector table from being relocated
   // This line needs to be commented out/not compiled for nRF52 targets
    #if !defined(TARGET_CUSTOM)
    SCB->VTOR = vtor;
    #endif
    SCB->AIRCR = 0x05FA | 0x0000;
    SCB->SCR = 0x00000000;
// SCB->CCR     - Implementation defined value
........

Once this is done, recompile your mbed-os libraries.

As far as the sample bootloader application goes, here's a stripped down version of mine that does exactly what you're doing:

/** Library includes */
#include "mbed.h"

extern "C" 
{
	#include "nrf_mbr.h"
	#include "nrf_sdm.h"
}


/** Application level includes */
#include "mbed_config.h"

// Branches execution to the main application in device flash
// Should not return
int loadMainApp(void)
{
	// Forward interrupts to the soft device
	sd_mbr_command_t l_Command = { .command = SD_MBR_COMMAND_INIT_SD};
	sd_mbr_command(&l_Command);

	// Disable SD (main application may re-enable SD)
	sd_softdevice_disable();

	uint32_t l_AppStartAddress = 0x1C000; // Your main application start address goes here

	// Configure SD to forward interrupts to application
	// TODO - Use configurable APP_CODE_BASE
	sd_softdevice_vector_table_base_set(l_AppStartAddress);

	// Branch to main application
	mbed_start_application(l_AppStartAddress);

	return 0; // Should never be reached
}

int main(void)
{
	loadMainApp();
}

Remember to set the UICR->BOOTLOADERADDR to point to your bootloader's start (10001014 -> 0x78000)

Thanks for your response Russ.

I wrote this question before I had actually started to implement a main application at all. This issue was experienced with just the bootloader trying to run when executed by the softdevice/mbr. Your answer was relevant when I actually was implementing the main application though.

Since my workaround seemed to work (I'm still not 100% comfortable with it) I went ahead and tried to get the application to run after the bootloader ran. This is where I experienced a problem with the mbed_application_start() function relocating the VTOR. I removed the line you mentioned above and the bootloader is successfully able to branch to the main application.

I'm still not sure why I have to do the strange interrupt routine workaround I posted in the original question... My original problem was happening immediately when the MBR tried to execute the bootloader, not when I was trying to branch to the main application. So I would imagine the VTOR would not be relocated by mbed until I called mbed_application_start() in the bootloader.

This interrupt issue has popped up before when I tried using Nordic's SAADC driver (without using mbed's AnalogIn api since my application required a bit more complexity). After initializing the Nordic SAADC driver my program would always lockup in an infinite loop - the same situation described above. Implementing a handler like this:

extern void SAADC_IRQHandler(void);

void SAADC_IRQHandler_v(void)
{
    SAADC_IRQHandler();
}

Allowed my program to execute as expected... In this case it was easy to guess which unimplemented IRQ handler was causing the lockup...

Any insight on this issue?

Hi George,

Even in the bootloader you'll need to relocate the vector table to RAM, otherwise you'll experience bugs with interrupts not working as expected. Normally this is done for you in nrf_reloc_vector_table() as part of the boot sequence. Is that line of code still getting called in the bootloader or did you remove it? If it is still present, is there a softdevice present to perform the vector table update?

The problem is that I have experienced this issue in a regular mbed application as well (no bootloader).

From my understanding, nrf_reloc_vector_table() is called in the startup_NRF528328.S assembly file and is part of the reset handler. I have not modified this file so it should be getting called still.

My application startup is as follows:

Power on/Reset -> MBR (0x0) -> Reads UICR->NRFFW[0] (BOOTLOADERADDR) -> Executes Bootloader from BOOTLOADERADDR -> Bootloader Program executes -> Branch to main application (at address 0x1C000) using modified mbed_start_application() -> Main application executes (softdevice/ble stack functions properly!)

I will try to make a really basic application that can reproduce this issue with the current release of mbed.

You guys are further along than I am. I'm not getting the bootloader to hand over control back to the main application. Our main application is using mBed OS 5.7.3 (#158) with softdevice but the bootloader is the a slightly modified sample "blinky" code from the nRF52 SDK 14 (without softdevice). I put the "bootloader" at 0x78000 and flash my mBed application as per usual (0x0000 - 0x52000). The main app works fine after I flash the "bootloader". When I update BOOTLOADERADDR UICR to point to 0x78000 (using <<code>>nrfjprog -f nrf52 --memwr 0x10001014 --val 0x78000<</code>>) and do a reset, it starts the "blinky" app correctly, but after a few blinks it is supposed to start the main app, but it just resets back to the "blinky" app. Also, when I write 0x1c000 to the BOOTLOADERADDR UICR and do a reset, I expected to get my mBed app running again, but that is not happening. Any insights?