nRF5 SDK for Mesh v0.10.1DFU Hangs?

RE: nRF5 SDK for Mesh v0.10.1DFU Hangs?

Jason Peterson — Thu, 02 Nov 2017 14:35:31 GMT

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.

RE: nRF5 SDK for Mesh v0.10.1DFU Hangs?

Jason Peterson — Thu, 02 Nov 2017 14:34:51 GMT

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

RE: nRF5 SDK for Mesh v0.10.1DFU Hangs?

Hung Bui — Thu, 02 Nov 2017 11:25:12 GMT

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.

RE: nRF5 SDK for Mesh v0.10.1DFU Hangs?

Jason Peterson — Wed, 01 Nov 2017 14:55:04 GMT

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"?

RE: nRF5 SDK for Mesh v0.10.1DFU Hangs?

Hung Bui — Wed, 01 Nov 2017 13:21:45 GMT

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 )

RE: nRF5 SDK for Mesh v0.10.1DFU Hangs?

Jason Peterson — Tue, 31 Oct 2017 21:12:19 GMT

When I use the "examples/dfu/bin/app_green_s130.hex" file to generate the DFU package and upload it It works!

However, when I use "/build/examples/dfu/dfu_nrf51422_xxAC_s130_2.0.1.hex" I get the error in my previous comment...?

RE: nRF5 SDK for Mesh v0.10.1DFU Hangs?

Jason Peterson — Tue, 31 Oct 2017 16:21:14 GMT

Yes, that worked. I upgraded my compiler to gcc-arm-none-eabi-6-2017-q2-update and now it seems to be running, however when I try a DFU it aborts:

RTT Log:

<t:        325>, main.c,  162, ----- Bluetooth Mesh DFU Example -----
<t:        345>, nrf_mesh_sdk.c,  181, Initializing softdevice
<t:          5>, nrf_mesh_sdk.c,  122, Initializing SoftDevice...
<t:         23>, nrf_mesh_sdk.c,  131, Ram base: 0x200022D8
<t:         92>, nrf_mesh_sdk.c,  140, sd_ble_enable: app_ram_base should be adjusted to 0x20001900
<t:        123>, nrf_mesh_sdk.c,  191, Initializing mesh stack
<t:       1316>, nrf_mesh_dfu.c,  528, 	RADIO TX! SLOT 0, count 255, interval: periodic, handle: FFFE
<t:       1348>, nrf_mesh_dfu.c,  561, 	SERIAL TX!
<t:       1371>, nrf_mesh_sdk.c,  198, Enabling mesh stack
<t:       1397>, serial_handler_prov.c,  212, Generating encryption keypair...
<t:      38419>, main.c,  186, Enabling serial interface...
<t:      38441>, main.c,  190, Initialization complete!
<t:     261902>, nrf_mesh_dfu.c,  390, 	New firmware!
<t:     261927>, nrf_mesh_dfu.c,  528, 	RADIO TX! SLOT 0, count 255, interval: periodic, handle: FFFD
<t:     261960>, nrf_mesh_dfu.c,  534, Killing a TX slot prematurely (repeats done: 0).
<t:     261986>, nrf_mesh_dfu.c,  561, 	SERIAL TX!
<t:     328229>, nrf_mesh_dfu.c,  528, 	RADIO TX! SLOT 0, count 255, interval: periodic, handle: FFFD
<t:     328262>, nrf_mesh_dfu.c,  534, Killing a TX slot prematurely (repeats done: 0).
<t:     328288>, nrf_mesh_dfu.c,  561, 	SERIAL TX!
<t:     394303>, nrf_mesh_dfu.c,  383, 	Abort event. Reason: 0xC
<t:     394328>, nrf_mesh_dfu.c,  528, 	RADIO TX! SLOT 0, count 255, interval: periodic, handle: FFFE
<t:     394361>, nrf_mesh_dfu.c,  534, Killing a TX slot prematurely (repeats done: 20).
<t:     394388>, nrf_mesh_dfu.c,  561, 	SERIAL TX!

nrfutil log:

nrfutil --verbose dfu serial -pkg ../build/examples/dfu/dfu_nrf51422_xxAC_s130_2.0.1.hex.zip -p /dev/tty.usbmodem1441 -b 115200 -fc --mesh
Upgrading target on /dev/tty.usbmodem1441 with DFU package /Users/jasonpeterson/Documents/nrf5_SDK_for_Mesh_v0-2a/build/examples/dfu/dfu_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: 93584
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: 1378fdff040fe064a2a659000000010002000000
target -> PC: 16a6045900000001000200000059000000010001000000
target -> PC: 03847800
PC -> target: 1378fdff040fe064a2a659000000010002000000
target -> PC: 03847800
PC -> target: 1478fcff0000e064a2a6ffffffff645b000000000c
target -> PC: 0ea30104590000000100020000000c
target -> PC: 03847800
Sending firmware file
  [------------------------------------]    1%  0d 00:11:52PC -> target: 1978fcff0100e064a2a6007d0020614b0200a14b0200f1b70100
target -> PC: 03847887
PC -> target: 1978fcff0100e064a2a6007d0020614b0200a14b0200f1b70100
target -> PC: 03847887

boot loader_verify:

python ../tools/dfu/bootloader_verify.py 680329450 /dev/tty.usbmodem1441 
Device family:			NRF51
Reading UICR..			OK.
Reading Device page..		OK.
Resetting device..		OK (In application)
Checking serial connection..	OK.

Bootloader verification OK.

here is how I am generating the dfu file:

nrfutil dfu genpkg --application ../build/examples/dfu/dfu_nrf51422_xxAC_s130_2.0.1.hex --company-id 0x00000059 --application-id 1 --application-version 2 --sd-req 0x0087 --mesh ../build/examples/dfu/dfu_nrf51422_xxAC_s130_2.0.1.hex.zip
Zip created at ../build/examples/dfu/dfu_nrf51422_xxAC_s130_2.0.1.hex.zip

RE: nRF5 SDK for Mesh v0.10.1DFU Hangs?

Hung Bui — Tue, 31 Oct 2017 13:20:00 GMT

Hi Jason,

Step through the code after a break point wouldn't work all the time. The reason is the Mesh stack uses the timeslot function on the softdevice. And the softdevice has some strict requirement on the timer . It crashes when you stop for a breakpoint. And most of the time you will end up in a hardfault if you step through a softdevice SVC call.

But from your log and what you have seen on the board, seems that there is an issue. The log should be something like this:

 0> <t:        292>, main.c,  162, ----- Bluetooth Mesh DFU Example -----
 0> <t:        308>, nrf_mesh_sdk.c,  181, Initializing softdevice
 0> <t:          0>, nrf_mesh_sdk.c,  122, Initializing SoftDevice...
 0> <t:         14>, nrf_mesh_sdk.c,  131, Ram base: 0x200022D8
 0> <t:         84>, nrf_mesh_sdk.c,  140, sd_ble_enable: app_ram_base should be adjusted to 0x20001900
 0> <t:        115>, nrf_mesh_sdk.c,  191, Initializing mesh stack
 0> <t:       1872>, nrf_mesh_dfu.c,  528, 	RADIO TX! SLOT 0, count 255, interval: periodic, handle: FFFE
 0> <t:       1902>, nrf_mesh_dfu.c,  561, 	SERIAL TX!
 0> <t:       1921>, nrf_mesh_sdk.c,  198, Enabling mesh stack
 0> <t:       1944>, serial_handler_prov.c,  212, Generating encryption keypair...
 0> <t:      39222>, main.c,  186, Enabling serial interface...
 0> <t:      39242>, main.c,  190, Initialization complete!

And the red LED should be on.

It's strange that it didn't throw any assertion in your case.

I attached here the hex file I used and it worked for me. Could you please check ? Make sure you trigger a reset using nrfjprog after you program. Many times I found SES make the chip hang after programming.

dfu_nrf51422_xxAC_s130_2.0.1.hex

RE: nRF5 SDK for Mesh v0.10.1DFU Hangs?

Jason Peterson — Mon, 30 Oct 2017 17:28:22 GMT

Yeah, pretty sure it was hanging so I just added the GBD stack trace see above.

RE: nRF5 SDK for Mesh v0.10.1DFU Hangs?

Hung Bui — Mon, 30 Oct 2017 13:55:03 GMT

Hi Jason,

Have you double checked that it's crashed ? I believe the log will be like that if you don't start any DFU command from the PC.