Getting hard fault when launching application from custom boot loader

RE: Getting hard fault when launching application from custom boot loader

henryh — Thu, 28 Jan 2021 16:26:02 GMT

I have resolved this issue by including the MBR in the firmware load, using it as a bootstrap to bring up my boot loader. My boot loader starts at 0x1000 so the MBR jumps into it directly after running. My bootloader uses a modified nrf_bootloader_app_start module to launch my application. After discovering that interrupts were causing erratic behavior I was able to determine that the MBR would solve this using "interrupt forwarding". It required some digging but I was finally able to find detailed information on the MBR boot process in the DevZone and was able to assemble the various modifications required for my needs. This is up and running now with full interrupt support and I ma moving onto other issues. Thank you for your help.

RE: Getting hard fault when launching application from custom boot loader

Jørgen Holmefjord — Mon, 18 Jan 2021 16:50:48 GMT

Hi,

I ran your projects and they seems to run correctly until I hit a HardFault inside nrf_drv_clock_hfclk_request() in sys_init/init_power_clock. I tracked this down to the CRITICAL_REGION_EXIT() macro at the end of the function, and specifically the call to __enable_irq(). The debugger reports that the application is in the Hardfault_Handler in the bootloader. Are you seeing the same problem, or are you able to pass this function call in the application? I would need to look some more into why this is happening.

[quote user="henryh"]1.) My application does not use an soft devices and I am running ESB for my wireless protocol. My plan is to write a simple boot loader that passes to the application using nrf_bootloader_app_start() with the vector table address changed to my application load address. Does this require a MBR? Is the MBR automatically inserted into a code load when running SES? If it does require an MBR where can I find detailed information on how to use it (please be specific)?[/quote]

The MBR is used for jumping to the bootloader (which is normally placed at the end of flash), and together with the softdevice. I cannot see any reasons that you should need it for your use-case. The MBR is a separate hex-file, it will not be merged with the application during build/flashing. The softdevice hex-files includes the MBR, but it is also available as a standalone hex-file for use with other bootloaders. Some SES projects are configured to flash the MBR hex-file along with the application (see Debug > Loader > Additional Load File[0]), but this is not the case with the projects you are using.

[quote user="henryh"]2.) Recently I wrote the application into flash with SES, switched to the boot loader and wrote it to memory. With this setup my code seemed to work until I erased all flash and tried to repeat the operation. After that point I could not get the application to launch from the boot loader (getting hard error). This suggests to me that the successful application boot was using something that was erased in the chip erase operation. I had previously been working with the application in a standard development environment (loaded at 0x0) so there was code in there that was obviously being used to run the application. Any idea how this might have worked?[/quote]

That sounds very strange, I would not think that any code outside the written bootloader/application areas should run. I have not seen this behavior with the projects you uploaded.

[quote user="henryh"]3.) When attempting to launch the application from the bootloader, I can follow execution from the application interrupt vector for a period of time but the it hits a hard fault whenever I let it free run. I suspect this is caused by a Nordic library module (USBD perhaps or ESB) that has an invalid jump address due to an incorrect SES build configuration. What is the correct procedure to configure SES to generate an image with a starting address other than 0x0? Do I need to allocate the flash memory range for soft devices to support Nordic library usage even though I am not using a soft device?[/quote]

I do not have a lot of experience with other setups than the one used by the SDK (MBR/softdevice in start of flash, bootlaoder at end of flash), but in theory it should just be to move the application start address and provide the correct address in the booloader. I'm not sure how ESB or USBD should be able to perform such a jump, that must be related to some interrupt handling or something similar. Changing the "Section Placement Macros" option should be sufficient to move the application in flash.

[quote user="henryh"]4.) The DFU module literature talks about using nrfprog to process an application for download into the Nordic flash memory allocation scheme. Is nrfprog remapping the application to the target address as part of this processing?[/quote]

Can you provide an exact link to where you read this? I'm not aware of any such features in nrfjprog. DFU are normally handled by nrfutil.

Best regards,
Jørgen

RE: Getting hard fault when launching application from custom boot loader

henryh — Wed, 13 Jan 2021 14:20:38 GMT

So I sent you the project files this morning in a private message but have some questions:

1.) My application does not use an soft devices and I am running ESB for my wireless protocol. My plan is to write a simple boot loader that passes to the application using nrf_bootloader_app_start() with the vector table address changed to my application load address. Does this require a MBR? Is the MBR automatically inserted into a code load when running SES? If it does require an MBR where can I find detailed information on how to use it (please be specific)?

2.) Recently I wrote the application into flash with SES, switched to the boot loader and wrote it to memory. With this setup my code seemed to work until I erased all flash and tried to repeat the operation. After that point I could not get the application to launch from the boot loader (getting hard error). This suggests to me that the successful application boot was using something that was erased in the chip erase operation. I had previously been working with the application in a standard development environment (loaded at 0x0) so there was code in there that was obviously being used to run the application. Any idea how this might have worked?

3.) When attempting to launch the application from the bootloader, I can follow execution from the application interrupt vector for a period of time but the it hits a hard fault whenever I let it free run. I suspect this is caused by a Nordic library module (USBD perhaps or ESB) that has an invalid jump address due to an incorrect SES build configuration. What is the correct procedure to configure SES to generate an image with a starting address other than 0x0? Do I need to allocate the flash memory range for soft devices to support Nordic library usage even though I am not using a soft device?

4.) The DFU module literature talks about using nrfprog to process an application for download into the Nordic flash memory allocation scheme. Is nrfprog remapping the application to the target address as part of this processing?

RE: Getting hard fault when launching application from custom boot loader

henryh — Tue, 12 Jan 2021 14:13:08 GMT

I should get a response out to you today.

RE: Getting hard fault when launching application from custom boot loader

Jørgen Holmefjord — Tue, 12 Jan 2021 13:54:57 GMT

I sendt you a PM regarding the project. Please let me know if you need further assistance with this and can provide the requested project.

RE: Getting hard fault when launching application from custom boot loader

Jørgen Holmefjord — Mon, 21 Dec 2020 18:53:59 GMT

Hi,

Not sure I understand exactly what you mean. Is the 8 bytes written to a specific address? Bootloader could be writing to the MBR_BOOTLOADER_ADDR (0xFF8) and/or MBR_PARAM_PAGE_ADDR (0xFFC).

Can you provide the hex file, map files, and a flash dump of the device?

Best regards,
Jørgen

RE: Getting hard fault when launching application from custom boot loader

henryh — Thu, 17 Dec 2020 19:08:09 GMT

I have verified that my bootloader is placing 8 bytes of data outside of the flash range reserved in the "section placement macros" in SES. The boot loader was set to start at 0x00000 with a size of 0x10000 and the application at 0x10000 with a size of 0x20000. This arrangement doesn't work since the boot_loader overwrites part of the application image if it is loaded second. Interestingly the 8 bytes are not contiguous but seem to be related to functions calls from the boot loader to NRF routines (2 examples follow).

static void lfclk_request(void)
{
    ret_code_t err_code = nrf_drv_clock_init();
//    APP_ERROR_CHECK(err_code);
    nrf_drv_clock_lfclk_request(NULL);
}

static void init_power_clock(void)
{
ret_code_t ret;

/* Initializing power and clock */
ret = nrf_drv_clock_init();
APP_ERROR_CHECK(ret);
ret = nrf_drv_power_init(NULL);
APP_ERROR_CHECK(ret);
nrf_drv_clock_hfclk_request(NULL);
nrf_drv_clock_lfclk_request(NULL);
while (!(nrf_drv_clock_hfclk_is_running() && nrf_drv_clock_lfclk_is_running()))
{
/* Just waiting */
}

/* Avoid warnings if assertion is disabled */
UNUSED_VARIABLE(ret);

return;
}//end function

I moved the application flash to start at 0x30000 and verified that the boot loader does not interfere with that range. Next I tried to load the full application with a "blinky" in the main line code. This application initializes the system to use the radio (ESB stack), USB, timers, SPI and various software constructs like FIFO's before running the blinky in main. I found that the system hits a hard fault when calling nrf_timer_task_trigger() in nrfx_timer_enable(), resulting in a constant reboot cycle. The code runs correctly if nrf_timer_task_trigger() is commented out. Any ideas what could be causing this?

I can send you the updated projects by email but would rather not post them in the forum.

RE: Getting hard fault when launching application from custom boot loader

henryh — Fri, 11 Dec 2020 14:52:48 GMT

I have resolved these issues and moved onto the full bootloader, which uses a USB driver based on one of your examples. The bootloader is setup to reside in flash at 0x0000-0xFFFF (64 KB) and the application at 0x20000-0x3FFFF (128 KB). I used this setup to test downloading the application into flash over USB and it worked correctly, including updating the CRC in a parameters block up at 0xFF000. I then download a new boot loader using the emulator in SES and it seems to be placing some NRF functions in the SD space identified in the Nordic literature (below 0x27000). I specifically noted that the USB driver did not function after programming flash, even though it was used in the image download. The section placement macros were set for FLASH_START=0x0 and FLASH_SIZE=0x10000 so I would expect SES to force the boot loader image in that region. I resolved this by moving the application start up to 0x30000 (inside the region reserved for the application the Nordic memory map) but am concerned that I don't fully understand how the sections are placed in flash. Is there another factor controlling the placement of these NRF functions in flash memory? Do I need to adhere to the Nordic memory map defined in the boot loader user guide?

RE: Getting hard fault when launching application from custom boot loader

Jørgen Holmefjord — Thu, 10 Dec 2020 11:16:47 GMT

I commented out a few header files that was not included in the packets you provided, for instance crc.h in util.c and nvmem.c, and radio.h in mvmem.c.

1. I'm not able to reproduce this. I just tested, and I hit the breakpoint on nrf_bootloader_app_start(), and I'm able to continue to a breakpoint on nrf_bootloader_app_start_final() which is hit twice before I get a HardFault. I assume this HardFault is expected as the bootloader have branched outside of the debugged application at this point.

2. Do this happen with every functions, or just the CRC functions? Is the HardFault happening immediately, or when jumping to the application. Could this be related to that the application works with crc header commented out on my test applications?

3. Not that I can think of, It should just take care of interrupt handling and then jump to the application.

RE: Getting hard fault when launching application from custom boot loader

henryh — Thu, 10 Dec 2020 00:07:42 GMT

Did you actually change something in the project or the code (beyond adding the LED commands)? This does seem to work now but I have a couple of issues:

1.) adding a break point on the call to nrf_bootloader_app_start() results in a hard fault. Why is that?

2.) There seems to be some connection between calling functions before nrf_bootloader_app_start() and a hard fault result. For example, a call to my CRC function to validate the application always results in a hard fault but replacing it with a simple query of a flag in flash memory (for example, the application size) seems to work all the time.

3.) Are there any conditions on using the nrf_bootloader_app_start() call?

Thank you

RE: Getting hard fault when launching application from custom boot loader

Jørgen Holmefjord — Wed, 09 Dec 2020 09:39:26 GMT

Well, the application starts at 0x10000 right, so there is no way for that to run on its own. I did not modify the start address.

I will send you the projects I used for testing, to see if there is any difference when you use those.

RE: Getting hard fault when launching application from custom boot loader

henryh — Tue, 08 Dec 2020 15:55:16 GMT

I am confused by your post. You stated that you added LED controls to the bootloader and application code and both execute correctly but didn't state the operating condition. Was this done by starting the bootloader and having it launch the application or was this done on each project in a stand alone manner?

RE: Getting hard fault when launching application from custom boot loader

henryh — Fri, 04 Dec 2020 21:13:36 GMT

I just implemented a similar "blinky" in both solutions, loaded the "app" at 0x10000 using SES and then ran the boot loader but all I get is a reboot into the bootloader application. I verified that the blinky worked in both applications before trying to boot the application from the bootloader. The bootoader lights come on but the code seem to consistently reboot at 0x0 instead of 0x10000.

RE: Getting hard fault when launching application from custom boot loader

henryh — Fri, 04 Dec 2020 20:34:31 GMT

I'm running this on a custom board with SES using JLINK. What do you mean by "DK as normal"?

RE: Getting hard fault when launching application from custom boot loader

Jørgen Holmefjord — Fri, 04 Dec 2020 11:30:22 GMT

Hi,

I tried adding some LED controls to both bootloader and application code, and both seems to execute correctly.

In main_bl.c, I set LED4 on the nRF52840 DK:

nrf_gpio_cfg_output(16);
nrf_gpio_pin_clear(16);

Similar, in main.c I set LED3:

nrf_gpio_cfg_output(15);
nrf_gpio_pin_clear(15);

Both light up when I run the DK as normal (not in debug interface mode).

Can you check if you are seeing similar behavior?

Best regards,
Jørgen

RE: Getting hard fault when launching application from custom boot loader

henryh — Mon, 30 Nov 2020 15:23:12 GMT

Any luck with the debug using the files I sent you?

RE: Getting hard fault when launching application from custom boot loader

Jørgen Holmefjord — Thu, 19 Nov 2020 14:46:46 GMT

Hi,

Would it be possible for you to share the full project for the bootloader and application? That way I can debug the HardFault and look for a solution for you.

Best regards,
Jørgen