Call to vPortStartFirstTask() fails in FreeRTOS when the MBR used without the Soft device

[Raiyan]

Hi All,

I am developing an application on nRF52840 Preview DK which does not need the Soft device. But it needs the MBR to run a bootloader for Firmware update purpose.

I've taken the MBR from Thread SDK as suggested in:

https://devzone.nordicsemi.com/f/nordic-q-a/31133/how-to-separate-the-mbr-from-the-softdevice

The size of the MBR is 0x1000. Therefore, I am setting the origin of the linker script at 0x1000.

The linker script I am using to build the application is as follows:

/* Linker script to configure memory regions. */

SEARCH_DIR(.)
GROUP(-lgcc -lc -lnosys)

MEMORY
{
  FLASH (rx) : ORIGIN = 0x1000, LENGTH = 0xFF000
  RAM (rwx) :  ORIGIN = 0x20000000, LENGTH = 0x40000
  UICR_APPROTECT (rx) : ORIGIN = 0x10001208, LENGTH = 0x4
}

SECTIONS
{
/* UICR. APPROTECT*/
  .uicrApprotectAddress :
  {
    KEEP(*(.uicrApprotectAddress))
  } > UICR_APPROTECT
}

SECTIONS
{
  . = ALIGN(4);
  .mem_section_dummy_ram :
  {
  }
  .log_dynamic_data :
  {
    PROVIDE(__start_log_dynamic_data = .);
    KEEP(*(SORT(.log_dynamic_data*)))
    PROVIDE(__stop_log_dynamic_data = .);
  } > RAM

} INSERT AFTER .data;

SECTIONS
{
  .mem_section_dummy_rom :
  {
  }
  .log_const_data :
  {
    PROVIDE(__start_log_const_data = .);
    KEEP(*(SORT(.log_const_data*)))
    PROVIDE(__stop_log_const_data = .);
  } > FLASH
  

} INSERT AFTER .text

INCLUDE "nrf5x_common.ld"

To develop the application I am using FreeRTOS.

I have noticed that if I set the origin of the application to 0x0, it works as expected. But if I set it to 0x1000 (as seen in the above linker script), the application halts.

 

As can be seen in above image , the call to vPortStartFirstTask() fails.

This does not happen when softdevice is installed or the origin is set to 0x0.

Could anyone suggest what is going wrong here?

[Raiyan]

Update:

I have changed line 9 of the linker file with the following line:

RAM (rwx) :  ORIGIN = 0x20000010, LENGTH = 0x3FFF0

This change made the problem disappear. But I don't know the reason behind it.

I cannot explain how leaving first 0x10 byte in RAM fixes the issue?

[Susheel Nuguru]

Impressive, you fixed the problem without knowing. So you have done your testing.

MBR itself uses some RAM (softdevice used or not (enabled or not)) and it is 8 bytes. You can find more information about it here. This page says that it is softdevice requirements, since they did not account for extracting MBR separately from softdevice.