This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf51822 Softdevice crash on SDK12.3

I have an application that is running for a while and then it crashes.

Execution goes to softdevice_fault_handler(), calling it with parameters: id=1; pc=0xf764; info=NULL

There is no helpful info in the call stack:

1. Is there a way to track where the crash is coming?

2. Can this be caused by having only 12 bytes of free RAM?

SDH:WARNING:sd_ble_enable: RAM start should be adjusted to 0x20001ff8
SDH:WARNING:RAM size should be adjusted to 0x2008 

I get this message when starting up the app, but is doesn't make sense since these are the values that I actually have configured

3. Sometimes I get this error while running in debug mode. It looks like this is just some error with the debugging session. If I attach the debugger again, I can see that the program still running and it doesn't look like it was restarted. Is there a way to avoid the debugging session from going down?

4. Is there a way to release some memory? Maybe removing sections from flash_placement?

<!DOCTYPE Linker_Placement_File>
<Root name="Flash Section Placement">
  <MemorySegment name="FLASH" start="$(FLASH_PH_START)" size="$(FLASH_PH_SIZE)">
    <ProgramSection load="no" name=".reserved_flash" start="$(FLASH_PH_START)" size="$(FLASH_START)-$(FLASH_PH_START)" />
    <ProgramSection alignment="0x100" load="Yes" name=".vectors" start="$(FLASH_START)" />
    <ProgramSection alignment="4" load="Yes" name=".init" />
    <ProgramSection alignment="4" load="Yes" name=".init_rodata" />
    <ProgramSection alignment="4" load="Yes" name=".text" />
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".sdh_soc_observers" inputsections="*(SORT(.sdh_soc_observers*))" address_symbol="__start_sdh_soc_observers" end_symbol="__stop_sdh_soc_observers" />
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".sdh_ble_observers" inputsections="*(SORT(.sdh_ble_observers*))" address_symbol="__start_sdh_ble_observers" end_symbol="__stop_sdh_ble_observers" />
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".pwr_mgmt_data" inputsections="*(SORT(.pwr_mgmt_data*))" address_symbol="__start_pwr_mgmt_data" end_symbol="__stop_pwr_mgmt_data" />
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".log_const_data" inputsections="*(SORT(.log_const_data*))" address_symbol="__start_log_const_data" end_symbol="__stop_log_const_data" />
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".sdh_req_observers" inputsections="*(SORT(.sdh_req_observers*))" address_symbol="__start_sdh_req_observers" end_symbol="__stop_sdh_req_observers" />
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".sdh_state_observers" inputsections="*(SORT(.sdh_state_observers*))" address_symbol="__start_sdh_state_observers" end_symbol="__stop_sdh_state_observers" />
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".sdh_stack_observers" inputsections="*(SORT(.sdh_stack_observers*))" address_symbol="__start_sdh_stack_observers" end_symbol="__stop_sdh_stack_observers" />
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".cli_command" inputsections="*(.cli_command*)" address_symbol="__start_cli_command" end_symbol="__stop_cli_command" />
    <ProgramSection alignment="4" keep="Yes" load="No" name=".nrf_sections" address_symbol="__start_nrf_sections" />
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".log_dynamic_data"  inputsections="*(SORT(.log_dynamic_data*))" runin=".log_dynamic_data_run"/>
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".fs_data"  inputsections="*(.fs_data*)" runin=".fs_data_run"/>
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".cli_sorted_cmd_ptrs"  inputsections="*(.cli_sorted_cmd_ptrs*)" runin=".cli_sorted_cmd_ptrs_run"/>
    <ProgramSection alignment="4" load="Yes" name=".dtors" />
    <ProgramSection alignment="4" load="Yes" name=".ctors" />
    <ProgramSection alignment="4" load="Yes" name=".rodata" />
    <ProgramSection alignment="4" load="Yes" name=".ARM.exidx" address_symbol="__exidx_start" end_symbol="__exidx_end" />
    <ProgramSection alignment="4" load="Yes" runin=".fast_run" name=".fast" />
    <ProgramSection alignment="4" load="Yes" runin=".data_run" name=".data" />
    <ProgramSection alignment="4" load="Yes" runin=".tdata_run" name=".tdata" />
    <ProgramSection alignment="4" load="No" name=".bootloaderSettings" start="0x0003FC00" size="0x400"/>
  </MemorySegment>
  <MemorySegment name="RAM" start="$(RAM_PH_START)" size="$(RAM_PH_SIZE)">
    <ProgramSection load="no" name=".reserved_ram" start="$(RAM_PH_START)" size="$(RAM_START)-$(RAM_PH_START)" />
    <ProgramSection alignment="0x100" load="No" name=".vectors_ram" start="$(RAM_START)" address_symbol="__app_ram_start__"/>
    <ProgramSection alignment="4" keep="Yes" load="No" name=".nrf_sections_run" address_symbol="__start_nrf_sections_run" />
    <ProgramSection alignment="4" keep="Yes" load="No" name=".log_dynamic_data_run" address_symbol="__start_log_dynamic_data" end_symbol="__stop_log_dynamic_data" />
    <ProgramSection alignment="4" keep="Yes" load="No" name=".fs_data_run" address_symbol="__start_fs_data" end_symbol="__stop_fs_data" />
    <ProgramSection alignment="4" keep="Yes" load="No" name=".cli_sorted_cmd_ptrs_run" address_symbol="__start_cli_sorted_cmd_ptrs" end_symbol="__stop_cli_sorted_cmd_ptrs" />
    <ProgramSection alignment="4" keep="Yes" load="No" name=".nrf_sections_run_end" address_symbol="__end_nrf_sections_run" />
    <ProgramSection alignment="4" load="No" name=".fast_run" />
    <ProgramSection alignment="4" load="No" name=".data_run" />
    <ProgramSection alignment="4" load="No" name=".tdata_run" />
    <ProgramSection alignment="4" load="No" name=".bss" />
    <ProgramSection alignment="4" load="No" name=".tbss" />
    <ProgramSection alignment="4" load="No" name=".non_init" />
    <ProgramSection alignment="4" size="__HEAPSIZE__" load="No" name=".heap" />
    <ProgramSection alignment="8" size="__STACKSIZE__" load="No" place_from_segment_end="Yes" name=".stack"  address_symbol="__StackLimit" end_symbol="__StackTop"/>
    <ProgramSection alignment="8" size="__STACKSIZE_PROCESS__" load="No" name=".stack_process" />
  </MemorySegment>
</Root>

Best regards,

Ricardo

Parents
  • Hi Ricardo,

    I assume you are suing S130 2.0.1? If so, the assert you get at 0x0000f764 indicate an assert caused by the SoftDevice missing a BLE event. Do you use the timeslot API? Or have long high priority interrupt routines, or critical sections?

    Einar

  • Hi Einar,

    Yes, I am using "s130_nrf51_2.0.1_softdevice.hex".

    I am using timers, app_scheduler library, and APP_UART_FIFO_INIT(), which calls a callback in an interreupt.

    The app_sched_event_put() function has a critical region, but it should be fast executing.

    Since yesterday I have:

    - made some optimizations to reduce memory usage to free up RAM for having another timer;

    - split the initial timer's tasks into two different timers, executing at different intervals;

    - moved some of the app_scheduler tasks to the new timer, because maybe I was scheduling too many tasks two quickly;

    - and reduced the number of events overall;

    The nrf app looks like it is now running more stable, so maybe it was just what you said. Some longer execution of some task.

    But this still leaves me wondering what exactly was the case and not knowing for sure if I fixed it or just reduced the frequency of the crashes (which is already a good thing, of course - but a better understanding of the problem would be even nicer).

    Is there a way I could find out what exactly was the issue? In what module or what call was taking longer than it should?

    Also, have you got the chance to look at point 4. from the original post?

    Best regards,

    Ricardo

Reply
  • Hi Einar,

    Yes, I am using "s130_nrf51_2.0.1_softdevice.hex".

    I am using timers, app_scheduler library, and APP_UART_FIFO_INIT(), which calls a callback in an interreupt.

    The app_sched_event_put() function has a critical region, but it should be fast executing.

    Since yesterday I have:

    - made some optimizations to reduce memory usage to free up RAM for having another timer;

    - split the initial timer's tasks into two different timers, executing at different intervals;

    - moved some of the app_scheduler tasks to the new timer, because maybe I was scheduling too many tasks two quickly;

    - and reduced the number of events overall;

    The nrf app looks like it is now running more stable, so maybe it was just what you said. Some longer execution of some task.

    But this still leaves me wondering what exactly was the case and not knowing for sure if I fixed it or just reduced the frequency of the crashes (which is already a good thing, of course - but a better understanding of the problem would be even nicer).

    Is there a way I could find out what exactly was the issue? In what module or what call was taking longer than it should?

    Also, have you got the chance to look at point 4. from the original post?

    Best regards,

    Ricardo

Children
  • Hi Ricardo,

    Ricardo Rodrigues said:
    Is there a way I could find out what exactly was the issue? In what module or what call was taking longer than it should?

    The SDK or SoftDevice does not have any specific support for that. It would have to be that you either inspect or profile the application in some way.

    Ricardo Rodrigues said:
    Also, have you got the chance to look at point 4. from the original post?

    Well. First of all it does not matter how much additional memory you have. As long as you are able to fit everything you are good. The exception is if you have a too small stack, and starts writing to RAM below the stack (stack overflow). I do not see anything in your question that indicate that this is a problem, though. Do you have any reason to think that this is a problem?

    If you want to free memory, you need to look at what you use. Removing something from flash_placement.xml does not help, as that just tells the linker where to put things. If you remove something that is unused, then it makes no difference. If you remove something that is used, then you will get a linker error.

    Einar

Related