Cannot download multiple load files because they overlap (external gcc with load script)

[RK01]

The Project (on a NRF52840) is setup to use an external toolchain (for C++) and we use the S140 softdevice (v7.2.0) for BLE stuff.

1. without loading the  S140 hex file and disable all related stuff in code and the following memory placement defined in the linker script:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x00100000
  RAM (rwx) :  ORIGIN = 0x20000000, LENGTH = 0x00040000
}

OK

2. now I add the S140 hex as additional load file and change the memory placement to:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x00027000, LENGTH = 0x000D9000
  RAM (rwx) :  ORIGIN = 0x20001678, LENGTH = 0x0003E900
}

build and link is OK but when download the the target i get 

I see a lot of problems in the Q&A but all with the SES section placement macros.

sources: Adjust RAM/Flash memory

EDIT 2022-02-03 14:14

When adjust the RAM/Flash values to something way bigger, it can flash but code is not working now: __NVIC_ClearPendingIRQ() in core_cm4.h fails.

MEMORY
{
  FLASH (rx) : ORIGIN = 0x00030000, LENGTH = 0x00070000
  RAM (rwx) :  ORIGIN = 0x20003000, LENGTH = 0x00030000
}

Downloading ‘s140_nrf52_7.2.0_softdevice.hex’ to J-Link
Programming 2.7 KB of addresses 00000000 — 00000aff
Programming 149.5 KB of addresses 00001000 — 00026633
J-Link: Flash download: Bank 0 @ 0x00000000: Skipped. Contents already match
Download successful
Downloading ‘Node.elf’ to J-Link
Programming 88.5 KB of addresses 00030000 — 0004621f
Programming 2.4 KB of addresses 00046220 — 00046beb
J-Link: Flash download: Bank 0 @ 0x00000000: 1 range affected (94208 bytes)
J-Link: Flash download: Total: 5.758s (Prepare: 0.277s, Compare: 0.065s, Erase: 1.929s, Program & Verify: 3.291s, Restore: 0.193s)
J-Link: Flash download: Program & Verify speed: 27 KB/s
Download successful

[Amanda Hsieh]

Hi, 

If you are using s140_nrf52_7.2.0_softdevice.hex, the application should start from 0x27000. Because the flash size of SD is 156 kB (0x27000 bytes), RAM is 5.6 kB (0x1678 bytes). You could try the following setting. If it still has the overlapping issue, you could use nRF Connect for Desktop/Programmer to check the memory layout. 

MEMORY
{
  FLASH (rx) : ORIGIN = 0x27000, LENGTH = 0xd9000
  RAM (rwx) :  ORIGIN = 0x20002300, LENGTH = 0x3dd00
}

Regards,
Amanda

[RK01]

Hi, 

Thank you, this is almost what I tired (RAM was different, why 0x20002300 and not 0x20001678?). I do not see any more information in the nRF Connect Programmer. 

If set the section in the flash higher (to 0x00030000 so it will flash but fail __NVIC_ClearPendingIRQ()) the Programmer layout looks like this.

[Amanda Hsieh]

Hi,

RK01 said:

Thank you, this is almost what I tired (RAM was different, why 0x20002300 and not 0x20001678?). I do not see any more information in the nRF Connect Programmer. 

Are you able to flash with nRF Connect Programmer? Would the application work?

RK01 said:

If set the section in the flash higher (to 0x00030000 so it will flash but fail __NVIC_ClearPendingIRQ()) the Programmer layout looks like this.

The application program code should be placed above the SoftDevice at APP_CODE_BASE. See Memory resource map and usage. 

-Amanda

[RK01]

Why should I programm the device with the nRF Connect Programmer instead of SES? 

I see the MBR and Softdevice are from 0x0 to 0x26633. So I should be able to load the application into 0x26634 or 0x26700 but that doesn't work. Below 0x30000 it complains about overlapping memory space. 

So I load it into 0x30000. Debug:

int main(int argc, char* argv[])
{
    using namespace std::placeholders; // for _1, _2
    ERROR_CHECK(app_timer_init());     //App Timer Init
    ....

in the app_timer_init() here it will fail:

static void timer_list_handler_sched(void)
{
    NVIC_SetPendingIRQ(SWI_IRQn);
}

it jumps to address 0xA60

Side note: the linked memory map is for the S112, here is the S140 Memory Map

[Amanda Hsieh]

Hi, 

I would suggest to use app_timer2.c which fixes some issues related to timeout handlers firing too soon and is generally much less complex. And it's API compatible with the old app_timer, so it should be an easy replacement. You can take a look at the  Template Application on how to use app_timer_init. 

-Amanda