RE: Weak Alias in nRF5 SDK for Mesh v0.10.1 DFU?

Hung Bui — Wed, 01 Nov 2017 13:18:07 GMT

Line 126 is a check for the state of the event .

I'm not sure why it would crash, but I think there will be some conflict integrating DFU and serial example together as both will use UART interface.

I would suggest to test first with the light control examples to get familiar with the DFU interface.

RE: Weak Alias in nRF5 SDK for Mesh v0.10.1 DFU?

Jason Peterson — Tue, 31 Oct 2017 16:02:23 GMT

Hi Hung,

Here it is, thanks for all the help!

/usr/local/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-addr2line -e ./examples/serial/serial_nrf51422_xxAC_s130_2.0.1.elf 0x00027776
    /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/mesh/core/src/timer_scheduler.c:126

RE: Weak Alias in nRF5 SDK for Mesh v0.10.1 DFU?

Hung Bui — Tue, 31 Oct 2017 14:27:37 GMT

Hi Jason,

Could you use addr2line.exe to check which function cause the issue ? It should be something like addr2line -e filename.elf 0x00027776

RE: Weak Alias in nRF5 SDK for Mesh v0.10.1 DFU?

Jason Peterson — Mon, 30 Oct 2017 17:49:01 GMT

I found what was causing the "weak alias" to be included. The "examples/serial/CMakeLists.txt" file did not include "${DFU_SOURCE_FILES}" I added it as follows:

add_executable(${target}
    "${CMAKE_CURRENT_SOURCE_DIR}/src/main.c"
    "${MBTLE_SOURCE_DIR}/examples/nrf_mesh_sdk.c"
    ${PROV_PROVISIONER_SOURCE_FILES}
    ${PROV_PROVISIONEE_SOURCE_FILES}
    ${PROV_COMMON_SOURCE_FILES}
    ${ACCESS_SOURCE_FILES}
    ${SERIAL_SOURCE_FILES}
    ${DFU_SOURCE_FILES}
    ${WEAK_SOURCE_FILES}
    ${${PLATFORM}_SOURCE_FILES})

After rebuilding with "${DFU_SOURCE_FILES}" I get the following:

<t:     183592>, main.c,   66, ----- Bluetooth Mesh Serial Interface Application -----
<t:     216385>, nrf_mesh_sdk.c,  181, Initializing softdevice
<t:          4>, nrf_mesh_sdk.c,  122, Initializing SoftDevice...
<t:         21>, nrf_mesh_sdk.c,  131, Ram base: 0x200022D8
<t:         90>, nrf_mesh_sdk.c,  140, sd_ble_enable: app_ram_base should be adjusted to 0x20001900
<t:       1417>, nrf_mesh_sdk.c,   78, MESH ASSERT at 0x00027776

Here is the backtrace:

Temporary breakpoint 1, main () at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/examples/serial/src/main.c:59
59	{
(gdb) continue
Continuing.
backtrace
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0001b40e in sleep_forever (pc=pc@entry=161654) at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/examples/nrf_mesh_sdk.c:64
64	    while (pc)
(gdb) backtrace
#0  0x0001b40e in sleep_forever (pc=pc@entry=161654) at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/examples/nrf_mesh_sdk.c:64
#1  0x0001b472 in mesh_assert_handler (pc=161654) at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/examples/nrf_mesh_sdk.c:79
#2  0x0002777e in add_to_add_list (p_evt=0x20003884 <m_timer>) at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/mesh/core/src/timer_scheduler.c:126
#3  timer_sch_schedule (p_timer_evt=p_timer_evt@entry=0x20003884 <m_timer>) at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/mesh/core/src/timer_scheduler.c:252
#4  0x00027bfe in ticker_init () at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/mesh/core/src/ticker.c:71
#5  0x0002711e in nrf_mesh_init (p_init_params=p_init_params@entry=0x20007cd0) at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/mesh/core/src/nrf_mesh.c:159
#6  0x0001b910 in mesh_core_setup () at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/examples/nrf_mesh_sdk.c:196
#7  0x0001b250 in main () at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/examples/serial/src/main.c:78

This looks related to my other question here now:

devzone.nordicsemi.com/.../