nRF Mesh DFU over the air

RE: nRF Mesh DFU over the air

Edvin — Mon, 20 Feb 2023 09:54:24 GMT

In case they do not reply, please create a new ticket where you describe in detail what happens when you try to run a DFU to another sample.

BR,

Edvin

RE: nRF Mesh DFU over the air

Shahin97 — Sat, 18 Feb 2023 18:55:26 GMT

lidorelias3 Have you tried DFU with other examples, instead of the Blinky? have you been able to flash them? I am only able to flash the Blinky

RE: nRF Mesh DFU over the air

lidorelias3 — Mon, 15 Aug 2022 18:31:13 GMT

Thanks in advance Edvin!

RE: nRF Mesh DFU over the air

Edvin — Tue, 09 Aug 2022 06:39:42 GMT

You need to let it wait a few seconds (10 seconds?) after it says "Device programmed.", and it should restart into the new FW. Please try with the unmodified DFU example first, to make sure that everything is set up correctly before you try to apply this to your own application.

BR,
Edvin

RE: nRF Mesh DFU over the air

lidorelias3 — Sat, 06 Aug 2022 22:25:44 GMT

I verified that the code I copied from the Mesh DFU example matches the code I have on my DK. After adding some missing stuff, I was able to DFU my DK!

nrfutil-mesh --verbose dfu serial -pkg blinky.zip -p COM3 -b 115200 --mesh
Upgrading target on COM3 with DFU package D:\Nordic\mesh-nrfutil\blinky.zip. Flow control is disabled.
Flushing com-port...
Opened com-port
Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 2180
Sending DFU start packet, afterwards we wait for the flash on target to be initialized before continuing.
1: PC -> target: 0502aabbccdd
target -> PC: 0582aabbccdd
Got echo response
Sending DFU init packet
Sending ready packet
1: PC -> target: 1378fdff040fe9016a5259000000010002000000
target -> PC: 16a6045900000001000200000059000000010001000000
target -> PC: 1378fdff04000000000059000000010002000000
target -> PC: 03847800
1: PC -> target: 1378fdff040fe9016a5259000000010002000000
target -> PC: 1378fdff040fe9016a5259000000010002000000
target -> PC: 03847800
Sending start packet
1: PC -> target: 1478fcff0000e9016a52ffffffff2102000000000c
target -> PC: 0da2010459000000010002000000
target -> PC: 03847800
Waiting for 0.0 seconds for flash bank erase to complete.
Sending firmware file
  [------------------------------------]    1%  00:08:411: PC -> target: 1978fcff0100e9016a520000012075c301005dc301005fc30100
target -> PC: 03847800
1: PC -> target: 1978fcff0200e9016a5261c3010063c3010065c3010000000000
target -> PC: 03847800
  [------------------------------------]    2%  00:08:341: PC -> target: 1978fcff0300e9016a5200000000000000000000000067c30100
target -> PC: 03847800
1: PC -> target: 1978fcff0400e9016a5269c30100000000006bc301006dc30100
target -> PC: 03847800
  [#-----------------------------------]    3%  00:05:371: PC -> target: 1978fcff0500e9016a526fc301006fc301006fc301006fc30100
target -> PC: 03847800
1: PC -> target: 1978fcff0600e9016a526fc301006fc301006fc301006fc30100
target -> PC: 03847800
......................
  [##################################--]   95%  00:00:031: PC -> target: 1978fcff8300e9016a52214602a8fff748fe039b002bf4d00198
target -> PC: 03847800
1: PC -> target: 1978fcff8400e9016a52d3e90021904702a8fff748fef4e70528
target -> PC: 03847800
  [###################################-]   97%  00:00:021: PC -> target: 1978fcff8500e9016a5201d0fff712fe04b010bd00bf74c80100
target -> PC: 03847800
1: PC -> target: 1978fcff8600e9016a5215c80100000000000d0e0f1000000000
target -> PC: 03847800
  [###################################-]   98%  00:00:001: PC -> target: 1978fcff8700e9016a520338fdd87047000050c8010058c80100
target -> PC: 03847800
1: PC -> target: 1978fcff8800e9016a520800000050c8010050c8010008000000
target -> PC: 03847800
  [####################################]  100%          1: PC -> target: 0d78fcff8900e9016a520090d003
target -> PC: 03847800
DFU upgrade took 86.2359998226s
Closing serial port...

Closing serial port...
Device programmed.

However, I see the following output in the debugger:

nrf_mesh_dfu.c,  593, 	SERIAL TX (type: 65534)
serial_handler_device.c,  125, Echo data: : AABBCCDD
nrf_mesh_dfu.c,  418, 	New firmware!
main.c,   72, DFU type Application
main.c,  117, Requesting DFU transfer with bank at 0x0004B000
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 0, count 3, interval: periodic, handle: FFFD
nrf_mesh_dfu.c,  593, 	SERIAL TX (type: 65533)
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 0, count 3, interval: periodic, handle: FFFD
nrf_mesh_dfu.c,  593, 	SERIAL TX (type: 65533)
nrf_mesh_dfu.c,  458, 	DFU start
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 6, count 6, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  357, Erase complete (0x4B000)
nrf_mesh_dfu.c,  361, Flash idle.
nrf_mesh_dfu.c,  482, 	DFU segment rx: 1/137
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 7, count 3, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  352, Write complete (0x2000FE98)
nrf_mesh_dfu.c,  361, Flash idle.
nrf_mesh_dfu.c,  482, 	DFU segment rx: 2/137
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 1, count 3, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  352, Write complete (0x2000FE98)
nrf_mesh_dfu.c,  361, Flash idle.
nrf_mesh_dfu.c,  482, 	DFU segment rx: 3/137
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 2, count 3, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  352, Write complete (0x2000FE98)
nrf_mesh_dfu.c,  361, Flash idle.
............
nrf_mesh_dfu.c,  482, 	DFU segment rx: 135/137
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 3, count 3, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  352, Write complete (0x2000FE98)
nrf_mesh_dfu.c,  361, Flash idle.
nrf_mesh_dfu.c,  482, 	DFU segment rx: 136/137
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 4, count 3, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  352, Write complete (0x2000FE98)
nrf_mesh_dfu.c,  361, Flash idle.
nrf_mesh_dfu.c,  482, 	DFU segment rx: 137/137
nrf_mesh_dfu.c,  629, 	TIMER set: 30000000us delay (@117850342)
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 5, count 3, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  352, Write complete (0x2000FE98)
nrf_mesh_dfu.c,  361, Flash idle.

As a result, my DK has two lights on and does not go to the new program I updated to (blinky example).

After restarting the device, it returns back to my program and not to the blinky example.

RE: nRF Mesh DFU over the air

lidorelias3 — Sat, 06 Aug 2022 21:37:16 GMT

I successfully performed a Mesh DFU using nRF5 SDK for Mesh 5.0.0 in combination with nRF5 SDK 17.0.2 using the example provided in Mesh 5.0.0. I received an ERROR_INVALID_DATA error when I tried to copy parts of the example into my program. From the example, I copied the relevant parts. Can I integrate Mesh DFU into my program this way?

Yes, the keys are correct. Checked it again.

My error may be related to how I copied the relevant part from the Mesh DFU example.

RE: nRF Mesh DFU over the air

Edvin — Thu, 04 Aug 2022 12:22:00 GMT

Is there some way for me to reproduce what you are seeing? I have been able to successfully perform a Mesh DFU using the nRF5 SDK for Mesh 5.0.0 in combination with nRF5 SDK 17.0.2. Did you try this?

Also, are you completely sure that you are using the correct keys? If you are not sure, please try to follow this guide, using an unmodified set of nRF5 SDK 17.0.2 and nRF5 SDK for Mesh v5.0.0.

At least, following this guide, I was able to upgrade the nRF52832 DK using the mesh bootloader.

Best regards,

Edvin

RE: nRF Mesh DFU over the air

lidorelias3 — Wed, 03 Aug 2022 17:21:56 GMT

D:\Nordic\mesh-nrfutil>nrfutil-mesh --verbose dfu serial -pkg dfu_test.zip -p COM3 -b 115200 --mesh
Upgrading target on COM3 with DFU package D:\Nordic\mesh-nrfutil\dfu_test.zip. Flow control is disabled.
Flushing com-port...
Opened com-port
Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 2416
Sending DFU start packet, afterwards we wait for the flash on target to be initialized before continuing.
1: PC -> target: 0502aabbccdd
target -> PC: 0582aabbccdd
Got echo response
Sending DFU init packet
Sending ready packet
1: PC -> target: 1378fdff040fd76e663c59000000020004000000
target -> PC: 16a6045900000002000400000059000000010001000000
target -> PC: 03847800
1: PC -> target: 1378fdff040fd76e663c59000000020004000000
target -> PC: 16a6045900000002000400000059000000010001000000
target -> PC: 03847800
Sending start packet
1: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
2: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
3: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
4: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
5: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
6: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
7: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
8: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
9: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
10: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887


Failed to upgrade target. Error is: Device returned status code ERROR_INVALID_DATA (135) on a DFU data packet.

Possible causes:
- bootloader, SoftDevice or application on target does not match the requirements in the DFU package.
- baud rate or flow control is not the same as in the target bootloader.
- target is not in DFU mode. If using the SDK examples, press Button 4 and RESET and release both to enter DFU mode.
- if the error is ERROR_BUSY at the beginning of the DFU process,increase the value of PAGE_ERASE_TIME_MAX by few milliseconds.
Closing serial port...

RE: nRF Mesh DFU over the air

Edvin — Tue, 02 Aug 2022 19:41:05 GMT

what does the cmd / terminal from nrfutil say when you try to perform the DFU at this point?

RE: nRF Mesh DFU over the air

lidorelias3 — Sun, 24 Jul 2022 18:57:39 GMT

Hey,

I added the log at line 226. As you suggested, I tried using a freshly unzipped MESH SDK. Now I only get the log "new firmware" at line 418, not the log at serial.c. As before, the DFU process doesn't work at all. I have no idea what the problem is.

RE: nRF Mesh DFU over the air

Edvin — Fri, 22 Jul 2022 18:25:07 GMT

Hello,

Sorry for the late reply. I have been out of office. I was back now only for a day. I'll be back August 1st. I am sorry I didn't have time to look into this now. Due to limited staffing during the summer, I don't think anyone will look into this case, so if you need a reply sooner, I suggest you try to create a new ticket where you describe your latest question. Please specify where it says "Error type data: : 0B".

A question that you can look into in the meantime is:

I see that your line numbers (from the log) are different than mine. Did you change anything inside these files? What is located in your nrf_mesh_dfu.c line 421, and serial.c line 226? I see that the nrf_mesh_dfu.c logging is just a few lines shifted, but none the less, it means that you changed something in this file. The logging from serial.c I can't find in my SDK, so did you add it yourself?

Perhaps you should try your application in a clean, unmodified, freshly unzipped SDK?

Best regards,

Edvin

RE: nRF Mesh DFU over the air

lidorelias3 — Fri, 08 Jul 2022 13:52:01 GMT

NRF_ERROR_NOT_SUPPORTED has been fixed. As you suggested, I used build and debug instead of attaching a debugger.

When transferring new firmware via serial connection, there is the same issue as before:

[quote userid="112929" url="~/f/nordic-q-a/88428/nrf-mesh-dfu-over-the-air/374247"]Error type data: : 0B[/quote]

What can be the cause for that?

RE: nRF Mesh DFU over the air

Edvin — Mon, 04 Jul 2022 13:36:32 GMT

[quote user="lidorelias3"]Is there a way to include those commands using Segger? [/quote]

I suggest you create a file that you call e.g.: "my_flash_script.bat", and then you paste those commands into that file (from a normal text editor). Then you can run this script from a command line whenever you do any updates, and it will flash all the required files. It is also possible to run this script from segger, if you enter the project settings (remember to select "common" from the drop down curtain menu), then go to Debug -> Target Script, and select the "Load begin script". You can remove the

program C:\Users\lidor\Desktop\netled\Netbag\build\serial_nrf52832_xxAA_s132_7.2.0_Debug\serial_nrf52832_xxAA_s132_7.2.0.hex

from your script, as this will be programmed by the program action in Segger. Or you can include it, and just run the script from the command line.

Please remember that when you are dealing with bootloaders like this, you should use the option "target -> Attach debugger" when you want to debug, as this will not upload a modified application .hex file, which may be rejected by the bootloader.

So nrf_mesh_dfu_init() returns NRF_ERROR_NOT_SUPPORTED. Try debugging to find out why.

Is it because dfu_cmd_handler_set() doesn't return NRF_SUCCESS? If so, what does it return?

Try to figure out why it returns what it returns, and perhaps you are able to determine the cause of the issue. If not, let me know what it returns.

BR,

Edvin

RE: nRF Mesh DFU over the air

lidorelias3 — Sun, 26 Jun 2022 17:26:09 GMT

Yes. The nrf_mesh_dfu_init() is being called but returns with NRF_ERROR_NOT_SUPPORTED.

The steps I did using the guide are:

nrfjprog --program bin/softdevice/s132_nrf52_7.2.0_softdevice.hex --chiperase

nrfjprog --program bin/bootloader/gccarmemb/mesh_bootloader_serial_gccarmemb_nrf52832_xxAA.hex

nrfjprog --program C:\Users\lidor\Desktop\netled\Netbag\build\serial_nrf52832_xxAA_s132_7.2.0_Debug\serial_nrf52832_xxAA_s132_7.2.0.hex

nrfjprog --program tools/dfu/bin/device_page_nrf52832_xxAA_s132_7.2.0.hex

nrfjprog --reset

Is there a way to include those commands using Segger?

Then I used Segger to attach a debugger and reboot the device. I saw that now I get something else on the console when I try to mesh-dfu. I hope that we get closer:

<t: 459057>, nrf_mesh_dfu.c, 421, New firmware!
<t: 525396>, nrf_mesh_dfu.c, 421, New firmware!
<t: 591620>, serial.c, 226, Error type data: : 0B
<t: 608136>, serial.c, 226, Error type data: : 0B
<t: 624934>, serial.c, 226, Error type data: : 0B
<t: 641662>, serial.c, 226, Error type data: : 0B
<t: 658498>, serial.c, 226, Error type data: : 0B
<t: 674908>, serial.c, 226, Error type data: : 0B
<t: 691812>, serial.c, 226, Error type data: : 0B
<t: 708616>, serial.c, 226, Error type data: : 0B
<t: 725453>, serial.c, 226, Error type data: : 0B
<t: 742297>, serial.c, 226, Error type data: : 0B

RE: nRF Mesh DFU over the air

Edvin — Tue, 21 Jun 2022 12:47:22 GMT

Did you do any modifications to the examples\dfu example, or are you trying to implement this into your own application?

Do you call nrf_mesh_dfu_init()?

I see that the "No CMD handler!" message is printed if there is no callback handler, which is being set in nrf_mesh_dfu_init(). By default, in the dfu example, this will be called from main() -> mesh_init() -> mesh_stack_init() -> nrf_mesh_init() -> nrf_mesh_dfu_init()

Can you make sure that is being called when you start up your application?

Also, can you share the steps that you did when you followed the guide. Did you follow steps 1 to 6? And did you encounter any issues along the way?

BR,

Edvin

RE: nRF Mesh DFU over the air

lidorelias3 — Mon, 20 Jun 2022 17:01:52 GMT

There are 41 lines in it, and I posted them all. I also have a bug on this forum where when I post a replay, I can only see it when I use the edit feature...

RE: nRF Mesh DFU over the air

Edvin — Mon, 20 Jun 2022 08:09:33 GMT

Does it stop after line 31, or did you just crop the output?

It may be caused by the keys. Did you generate your own keypair and use them in the devicepages?

RE: nRF Mesh DFU over the air

lidorelias3 — Sun, 19 Jun 2022 20:52:17 GMT

RE: nRF Mesh DFU over the air

Edvin — Thu, 16 Jun 2022 11:58:42 GMT

Did you do any changes to the flash_placement file? If so, try to revert those changes.

I take it you are using SES, then.

Did you remember to select "Common" from the drop down menu before changing the start address?

RE: nRF Mesh DFU over the air

lidorelias3 — Wed, 15 Jun 2022 16:37:41 GMT

In the flash_placement.xml I have:

<!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_ant_observers" inputsections="*(SORT(.sdh_ant_observers*))" address_symbol="__start_sdh_ant_observers" end_symbol="__stop_sdh_ant_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=".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_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=".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=".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=".nrf_balloc" inputsections="*(.nrf_balloc*)" address_symbol="__start_nrf_balloc" end_symbol="__stop_nrf_balloc" />
<ProgramSection alignment="4" keep="Yes" load="Yes" name=".nrf_queue" inputsections="*(.nrf_queue*)" address_symbol="__start_nrf_queue" end_symbol="__stop_nrf_queue" />
<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="Yes" name=".crypto_data" inputsections="*(SORT(.crypto_data*))" address_symbol="__start_crypto_data" end_symbol="__stop_crypto_data" />
<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_backends" inputsections="*(SORT(.log_backends*))" address_symbol="__start_log_backends" end_symbol="__stop_log_backends" />
<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=".log_filter_data" inputsections="*(SORT(.log_filter_data*))" runin=".log_filter_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" keep="Yes" load="Yes" name=".fs_data" inputsections="*(.fs_data*)" runin=".fs_data_run"/>
<ProgramSection alignment="4" keep="Yes" load="Yes" name=".nrf_mesh_flash" inputsections="*(SORT(.nrf_mesh_flash.*))" address_symbol="__start_nrf_mesh_flash" end_symbol="__stop_nrf_mesh_flash"/>
<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" />
</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=".log_filter_data_run" address_symbol="__start_log_filter_data" end_symbol="__stop_log_filter_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=".fs_data_run" address_symbol="__start_fs_data" end_symbol="__stop_fs_data" />
<ProgramSection alignment="4" keep="Yes" load="No" name=".nrf_sections_run_end" address_symbol="__end_nrf_sections_run" />
<ProgramSection alignment="4" keep="Yes" load="No" name=".nrf_mesh_ram" inputsections="*(SORT(.nrf_mesh_ram.*))" address_symbol="__start_nrf_mesh_ram" end_symbol="__stop_nrf_mesh_ram"/>
<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>

And in the .emProject file I have the macro called RAM_START. So I changed it to 0x20002DF0.
When run again it stays on the old address

Does the application key means the public encryption key? where does the public and private keys which I generated and concated in the .json file stored?

RE: nRF Mesh DFU over the air

Edvin — Tue, 14 Jun 2022 08:57:21 GMT

How did you change your ram start address? Can you show me a screenshot?
You should only need to send the application serial to one device. The other devices in the network with the same application ID and application key in their device page. But the device page must also be flashed on all other devices.

RE: nRF Mesh DFU over the air

lidorelias3 — Mon, 13 Jun 2022 11:44:06 GMT

I did change the default UART pins in the application, and I noticed that we canceled the flow control.

In order to make it work, I had to remove the fc flag.

However, it only updates the one board connected via serial to the computer. Are all the other devices supposed to receive the update? I need the board connected via serial to send the DFU package to the other devices, which will then be updated.

And another question is - How should I use this example in my program?

I tried to copy the main parts from the application and now when I compile and run the program I get the following error:

ble_softdevice_support.c,  171, sd_ble_enable: app_ram_base should be adjusted to 0x20002DF0

When I try to change the app ram start address it never changed.

Is that how I suppose to do that? Why I got this error?

RE: nRF Mesh DFU over the air

Edvin — Mon, 13 Jun 2022 08:08:14 GMT

What HW are you running this on? An nRF52832 DK?

Did you change the default UART pins in your application, or are they still the default settings?

Can you try to set a breakpoint in serial_handler_device.c in the handle_cmd_device_echo() callback, and see whether that triggers?

Best regards,

Edvin

RE: nRF Mesh DFU over the air

lidorelias3 — Sun, 12 Jun 2022 15:09:43 GMT

I tried.. The same happens - The board light turns on and when using the nrfutil for mesh it still failed to establish connection.

RE: nRF Mesh DFU over the air

Edvin — Tue, 07 Jun 2022 06:54:11 GMT

Ok. Try the other one (dfu_nrf52832_xxAA_s132_7_2_0.emProject), and let me know if that also doesn't work.