nRF5 SDK for Mesh v0.10.1DFU Hangs?

[Jason Peterson]

Hello,

I am working with the nRF-SDK-for-Mesh v0.10.1 I am able to compile and run everything fine. However the DFU example hangs. It looks like a hard fault ( all the LEDs are on).

I am following the guide from the SDK docs here:

infocenter.nordicsemi.com/.../md_doc_getting_started_dfu_quick_start.html

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

DFU: /build/examples/dfu/dfu_nrf51422_xxAC_s130_2.0.1.hex

When running the DFU example It hangs during mesh stack initialization in "nrf_mesh_int()" from "nrf_mesh.c" around line 145 I believe in the "core_tx_init()" function. I have tried the serial example which has similar init code and it works fine (except it doesn't except DFU commands because for some reason it is linking the "_weak" functions in "nerf_mesh_weak.c" instead of the real ones (I am posting this in another question).

Here is the RTT Trace:

<t:        265>, main.c,  162, ----- Bluetooth Mesh DFU Example -----
<t:        281>, 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:         84>, 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

Thank you!

Here is the stack trace:

Temporary breakpoint 1, main () at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/examples/dfu/src/main.c:153
153	{
(gdb) continue
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
sleep_forever (pc=pc@entry=1) at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/examples/nrf_mesh_sdk.c:64
64	    while (pc)
(gdb) backtrace
#0  sleep_forever (pc=pc@entry=1) at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/examples/nrf_mesh_sdk.c:64
#1  0x0001b88e in HardFault_Handler () at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/examples/nrf_mesh_sdk.c:85
#2  <signal handler called>
#3  0x00026c74 in timer_on_ts_begin (timeslot_start_time=0) at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/mesh/core/src/timer.c:304
#4  0x00026f92 in on_ts_begin (p_timeslot=0x200038e0 <m_current_timeslot>) at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/mesh/core/src/timeslot.c:180
#5  0x0002706c in handle_extend_end (p_timeslot=p_timeslot@entry=0x200038e0 <m_current_timeslot>, success=success@entry=true)
    at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/mesh/core/src/timeslot.c:317
#6  0x000270fa in radio_signal_callback (sig=<optimized out>) at /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/mesh/core/src/timeslot.c:396
#7  0x0001a2b0 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[Hung Bui]

Could you let me know how you fix the issue in the initial question ? The hex file I provided to you simply the stock example, I didn't modify anything.

Regarding the issue when you try to update dfu application, I think it's because the size of the DFU application is too big for DFU update. Note that we need 2 banks to do background DFU. So the size of the application should not exceed 50% of the space for application (Total flash - softdevice - bootloader )

[Jason Peterson]

I think it was RAM corruption by the RTT after using this post: devzone.nordicsemi.com/.../ I was trying desperately to get some RTT output and forgot that I had modified the linker script. I started from scratch and upgraded my compiler from "gcc-arm-none-eabi-5_4-2016q3" to "gcc-arm-none-eabi-6-2017-q2-update" then everything worked including RTT.

So the "DFU example" can't be used to update itself? Is there anything I can do about that? Am I correct in thinking that as it sits now it looks like I can only use DFU once because the new application has to be smaller then the "DFU Example"?

[Hung Bui]

If you don't plan to use any extra feature on S130, you can consider using S110 instead. This will save you about 22kB. Also when you compile please use Release version so the size of the application can be compressed a little bit.

It's easier on nRF52 series where we have more flash space.

When you update firmware in a mesh network, you can choose different application IDs, so that for example the DFU gateway can have different application ID won't be updated, only the normal nodes get new image. An application without DFU serial interface (normal node) will have smaller size.

[Jason Peterson]

Ok, thank you for all the help! I will give those things a try.

[Jason Peterson]

I think it was RAM corruption by the RTT after using this post: devzone.nordicsemi.com/questi... I was trying desperately to get some RTT output and forgot that I had modified the linker script. I started from scratch and upgraded my compiler from "gcc-arm-none-eabi-5_4-2016q3" to "gcc-arm-none-eabi-6-2017-q2-update" then everything worked including RTT.