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

[Jason Peterson]

Hello,

I am working with the nRF-SDK-for-Mesh v0.10.1 I am able to compile and run everything fine. I am trying to use the "serial" example and perform a DFU, however the DFU functions in"nrf_mesh_weak.c" are getting linked instead of the real ones in "nrf_mesh_dfu.c"

I verified this by adding a log in "nrf_mesh_weak.c" here:

uint32_t _weak_handler()
{
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "_weak_handler...\n");
    return NRF_ERROR_NOT_SUPPORTED;
}

I am following the guide from the SDK docs here:

infocenter.nordicsemi.com/topi...

I am using:

PCA10031, nrf51422, s130

SoftDevice: /external/softdevice/s130_2.0.1/s130_nrf51_2.0.1_softdevice.hex

Bootloader: /bin/bootloader_serial_xxAC.hex

Application: /build/examples/serial/serial_nrf51422_xxAC_s130_2.0.1.hex

Here is the RTT trace:

<t:        256>, main.c,   66, ----- Bluetooth Mesh Serial Interface Application -----
<t:      33041>, nrf_mesh_sdk.c,  181, Initializing softdevice
<t:          4>, nrf_mesh_sdk.c,  122, Initializing SoftDevice...
<t:         18>, nrf_mesh_sdk.c,  131, Ram base: 0x200022D8
<t:         85>, nrf_mesh_sdk.c,  140, sd_ble_enable: app_ram_base should be adjusted to 0x20001900
<t:        110>, nrf_mesh_sdk.c,  191, Initializing mesh stack
<t:       1356>, nrf_mesh_weak.c,   54, _weak_handler...
<t:       1373>, nrf_mesh_sdk.c,  198, Enabling mesh stack
<t:       1415>, main.c,   84, Enabling ECDH offloading...
<t:       1431>, main.c,   88, Enabling serial interface...
<t:       1446>, serial_handler_prov.c,  212, Generating encryption keypair...
<t:      36079>, main.c,   92, Initialization complete!

I am running the DFU with this command:

nrfutil --verbose dfu serial -pkg ../build/examples/serial/serial_nrf51422_xxAC_s130_2.0.1.hex.zip -p /dev/tty.usbmodem1441 -b 115200 -fc --mesh

Here is the output:

Upgrading target on /dev/tty.usbmodem1441 with DFU package /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/build/examples/serial/serial_nrf51422_xxAC_s130_2.0.1.hex.zip. Flow control is enabled.
  [------------------------------------]    0%
Flushing com-port...
Opened com-port
Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 118488
Sending DFU start packet, afterwards we wait for the flash on target to be initialized before continuing.
PC -> target: 0502aabbccdd
target -> PC: 0582aabbccdd
Got echo response
Sending DFU init packet
PC -> target: 1378fdff040f3836681359000000010002000000
target -> PC: 0384788e

Here is the RTT trace:

<t:    2492322>, nrf_mesh_weak.c,   54, _weak_handler...

What am I missing? Thank You!

[Jason Peterson]

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/.../

[Hung Bui]

Hi Jason,

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

[Jason Peterson]

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

[Hung Bui]

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.