linker script and HardFault

RE: linker script and HardFault

Tamas Selmeci — Mon, 28 Jan 2019 13:10:27 GMT

Thanks for this, I've increased the RAM origin address by 0x1000. I hope this'll be enough for the SoftDevice.

RE: linker script and HardFault

AndreasF — Mon, 28 Jan 2019 11:54:05 GMT

Hi.

Glad you found it, I didn't get your reply before making a comment.

Good luck with further development.

Best regards,

Andreas

RE: linker script and HardFault

AndreasF — Mon, 28 Jan 2019 11:52:24 GMT

Hi.

The flash address is correct for S132 V6.1.0. The ram address should not have any impact on the starting of the application. If it is wrong, then you might experience a memory corruption very quickly. Are you sure that the value you have set for the RAM start address is correct? It seems quite low (i.e. the lowest possible value), and it could be that you application is starting but gets a corrupted memory very quickly. If you are using a number of features in the SoftDevice, then the RAM start address should be higher.

For example, take a look at the linker script for the ble_app_blinky example:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x5a000
  RAM (rwx) :  ORIGIN = 0x200022b8, LENGTH = 0xdd48
}

The blinky example uses for example RTC0, TIMER0, Radio, ECB, and LF clock, which all requires the SoftDevice.

Therefore the RAM start address is set much higher than the lowest value.

Best regards,

Andreas

RE: linker script and HardFault

Tamas Selmeci — Mon, 28 Jan 2019 10:45:51 GMT

I've got it. My compile flags are bit different than the flags in the SDK, but in general this doesn't cause any issue, except for a linker flag:

-Wl,--start-group

After uncommenting this (and using the proper linker file above) the app began working.

RE: linker script and HardFault

Tamas Selmeci — Mon, 28 Jan 2019 08:33:12 GMT

No success. I've created a hybrid linker file with the correct flash and RAM addresses/sizes, but my app still doesn't work. If the very same app is linked with the linker file without extra sections, it's okay.

Here's the correct linker file:

/* Linker script to configure memory regions. */

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

MEMORY
{
  FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x5a000
  RAM (rwx) :  ORIGIN = 0x20001628, LENGTH = 0xe9d8
}

SECTIONS
{
}

SECTIONS
{
  . = ALIGN(4);
  .mem_section_dummy_ram :
  {
  }

} INSERT AFTER .data;

SECTIONS
{
  .mem_section_dummy_rom :
  {
  }

} INSERT AFTER .text

INCLUDE "nrf_common.ld"

And here's the wrong. As you can see, I've just added the extra sections, but it caused some troubles.

/* Linker script to configure memory regions. */

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

MEMORY
{
  FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x5a000
  RAM (rwx) :  ORIGIN = 0x20001628, LENGTH = 0xe9d8
}

SECTIONS
{
}

SECTIONS
{
  . = ALIGN(4);
  .mem_section_dummy_ram :
  {
  }
  .cli_sorted_cmd_ptrs :
  {
    PROVIDE(__start_cli_sorted_cmd_ptrs = .);
    KEEP(*(.cli_sorted_cmd_ptrs))
    PROVIDE(__stop_cli_sorted_cmd_ptrs = .);
  } > RAM
  .fs_data :
  {
    PROVIDE(__start_fs_data = .);
    KEEP(*(.fs_data))
    PROVIDE(__stop_fs_data = .);
  } > RAM
  .log_dynamic_data :
  {
    PROVIDE(__start_log_dynamic_data = .);
    KEEP(*(SORT(.log_dynamic_data*)))
    PROVIDE(__stop_log_dynamic_data = .);
  } > RAM
  .log_filter_data :
  {
    PROVIDE(__start_log_filter_data = .);
    KEEP(*(SORT(.log_filter_data*)))
    PROVIDE(__stop_log_filter_data = .);
  } > RAM

} INSERT AFTER .data;

SECTIONS
{
  .mem_section_dummy_rom :
  {
  }
  .sdh_ant_observers :
  {
    PROVIDE(__start_sdh_ant_observers = .);
    KEEP(*(SORT(.sdh_ant_observers*)))
    PROVIDE(__stop_sdh_ant_observers = .);
  } > FLASH
  .sdh_ble_observers :
  {
    PROVIDE(__start_sdh_ble_observers = .);
    KEEP(*(SORT(.sdh_ble_observers*)))
    PROVIDE(__stop_sdh_ble_observers = .);
  } > FLASH
  .sdh_soc_observers :
  {
    PROVIDE(__start_sdh_soc_observers = .);
    KEEP(*(SORT(.sdh_soc_observers*)))
    PROVIDE(__stop_sdh_soc_observers = .);
  } > FLASH
  .sdh_stack_observers :
  {
    PROVIDE(__start_sdh_stack_observers = .);
    KEEP(*(SORT(.sdh_stack_observers*)))
    PROVIDE(__stop_sdh_stack_observers = .);
  } > FLASH
  .sdh_req_observers :
  {
    PROVIDE(__start_sdh_req_observers = .);
    KEEP(*(SORT(.sdh_req_observers*)))
    PROVIDE(__stop_sdh_req_observers = .);
  } > FLASH
  .sdh_state_observers :
  {
    PROVIDE(__start_sdh_state_observers = .);
    KEEP(*(SORT(.sdh_state_observers*)))
    PROVIDE(__stop_sdh_state_observers = .);
  } > FLASH
    .nrf_queue :
  {
    PROVIDE(__start_nrf_queue = .);
    KEEP(*(.nrf_queue))
    PROVIDE(__stop_nrf_queue = .);
  } > FLASH
    .nrf_balloc :
  {
    PROVIDE(__start_nrf_balloc = .);
    KEEP(*(.nrf_balloc))
    PROVIDE(__stop_nrf_balloc = .);
  } > FLASH
    .cli_command :
  {
    PROVIDE(__start_cli_command = .);
    KEEP(*(.cli_command))
    PROVIDE(__stop_cli_command = .);
  } > FLASH
  .crypto_data :
  {
    PROVIDE(__start_crypto_data = .);
    KEEP(*(SORT(.crypto_data*)))
    PROVIDE(__stop_crypto_data = .);
  } > FLASH
  .pwr_mgmt_data :
  {
    PROVIDE(__start_pwr_mgmt_data = .);
    KEEP(*(SORT(.pwr_mgmt_data*)))
    PROVIDE(__stop_pwr_mgmt_data = .);
  } > FLASH
  .log_const_data :
  {
    PROVIDE(__start_log_const_data = .);
    KEEP(*(SORT(.log_const_data*)))
    PROVIDE(__stop_log_const_data = .);
  } > FLASH
  .log_backends :
  {
    PROVIDE(__start_log_backends = .);
    KEEP(*(SORT(.log_backends*)))
    PROVIDE(__stop_log_backends = .);
  } > FLASH

} INSERT AFTER .text

INCLUDE "nrf_common.ld"

I'll check whether my compile flags are correct. Perhaps another SDK version would also suit...

RE: linker script and HardFault

Tamas Selmeci — Thu, 24 Jan 2019 07:34:17 GMT

Good idea. I'll try all your recommendations on the next week (I'm out of office at the moment) and reflect.

RE: linker script and HardFault

wpaul — Wed, 23 Jan 2019 17:30:34 GMT

Make sure you adjust the length too. (It should be 512KB - 0x26000, i.e. 0x5A000.)

I would use the debugger to set a breakpoint at 0x26000 and then launch the target and see if it gets there. This will at least tell you if the start-up code is doing the right thing. If the breakpoint doesn't trigger, then something is going wrong before even reaching your application. If the breakpoint does trigger, then dump what's at 0x26000 to see if it looks like valid code and try single-stepping to see where it goes wrong.

RE: linker script and HardFault

AndreasF — Wed, 23 Jan 2019 07:51:17 GMT

Hi.

You could take a look at the tutorial for adjustment of RAM and Flash memory.

Best regards,

Andreas

RE: linker script and HardFault

Tamas Selmeci — Wed, 23 Jan 2019 07:38:27 GMT

Thanks for the answer, it's all clear to me. I've already figured out that the app start address is different in the mentioned linker files and created a new linker file with the correct start address (0x26000), but it again failed to execute correctly. Maybe I did something wrong, I'll give it a next try and share the results here.

RE: linker script and HardFault

wpaul — Tue, 22 Jan 2019 18:43:09 GMT

If you're using a custom application with no SoftDevice (and no bootloader), then your application code is expected to be placed at address 0x0 in the flash.

But when using the S132 SoftDevice, the MBR and SoftDevice take up a portion of the flash starting from address 0, and user application code is expected to start at a specific offset in flash _after_ the SoftDevice. The exact offset varies slightly depending on the SoftDevice release, but it's always documented in the SoftDevice release notes. It also has to be included in the linker script when linking your application code.

In the first script file you mention, it says this:

MEMORY
{
FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x5a000
RAM (rwx) : ORIGIN = 0x200014b8, LENGTH = 0xeb48
}

But in the second it says this:

MEMORY
{
FLASH (rx) : ORIGIN = 0x2d000, LENGTH = 0x53000
RAM (rwx) : ORIGIN = 0x20001f30, LENGTH = 0xe0d0
}

I happen to know that 0x26000 is the correct application offset address for the S132 SoftDevice (and coincidentally also for the S140 SoftDevice). The start-up code in the MBR, which is the first thing to run when you boot the CPU, expects the application code to be located at 0x26000, so after a little bit of set-up it will try to jump there. If you use the second script, your application won't be there: it will be at 0x2d000 instead. So when the CPU branches to 0x26000 there will be just 0xFF bytes there, and the CPU will interpret them as illegal instructions and you'll end up in the HardFault handler.

The RAM definition is also important, because some of the RAM must also be reserved for use by the SoftDevice once it's been enabled. Exactly how much RAM has to be reserved depends a little bit on exactly what BLE features you use, and other things like how many simultaneous connections you want to support. Some of the SoftDevice APIs will return an error if you don't reserve enough RAM -- they also indicate how much RAM should be available which tells you how to adjust things.

So if you want to use the second script with the SoftDevice, you have to adjust the FLASH and RAM definitions accordingly. You can try just copying the entries from the first script into the second one and see if that at least gets your application to start up.