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]

Good to know you find the issue.

-Amanda

[RK01]

I did not.

Still Error cannot download multiple load files because they overlap when using the linker scripts from the examples with adjusted FLASH/RAM origin/lenght as suggested.

[Amanda Hsieh]

Hi,

RK01 said:

The problem arises when switching to external gcc toolchain and using the linker script. The problem is probably in the linker script (I copied these from the examples) or in the project settings. 

What do you mean by the "external gcc toolchain"? Are you using SDK17.1? If so, it only supports GCC ARM Embedded 9.2020-q2.major. See the SDK Release Notes. 

RK01 said:

Still Error cannot download multiple load files because they overlap when using the linker scripts from the examples with adjusted FLASH/RAM origin/lenght as suggested.

Are you using the external gcc with the linker scripts from the examples with adjusted FLASH/RAM origin/lenght as suggested? If so, that might be the issue. I would suggest to use SES internal gcc as you said that can work. 

RK01 said:

Also our own project is OK when using the flash_placement.xml and SES internal gcc. 

-Amanda

[RK01]

- SDK 17.0.2 (edit: Updated to 17.1.0, same result)

- GNU Arm Embedded Toolchain 9 2020-q2-update (I did not find the q2-major)

- S140 7.2.0

Amanda Hsieh said:

Are you using the external gcc with the linker scripts from the examples with adjusted FLASH/RAM origin/lenght as suggested?

Yes. 

Yes from the examples\ble_peripheral\ble_app_blinky\pca10056\s140\armgcc

Amanda Hsieh said:

If so, that might be the issue. I would suggest to use SES internal gcc as you said that can work. 

To clarify it works if C only! But we need C++. And this is not possible with the SES internal gcc, so I am forced to use the external gcc.

[Amanda Hsieh]

Hi, 

Seem the issue might be in the external gcc or Segger, so I would suggest to contact Segger https://www.segger.com/support/technical-support/ or the external gcc provider.  

Please be aware that Nordic doesn't have any official support for C++ in SES (or C++ in any other compiler), so I'm afraid you have to figure this out yourself. 

-Amanda