Custom DFU transport over mesh (NCS 1.6)

[ipshiv]

Good day!

I have a problem with bootloader and custon DFU transport on nRF52840. What I do:

1. Transfer DFU over mesh using vendor model (it was implemented for MESH SDK, had been tested and successfully worked before NCS migration);
2. Use dfu target mcuboot to store new FW on flash (also tried to save it directly using stream flash and mcuboot api for update)
3. After transfer and reboot board turns off for a bout half minute and turns back to primary slot.

Is it possible to do DFU this way? Or I should use MCUMGR?

Also I can't figure out flash map. I found that PM manager overrides dts, fine. Secondary address starts from 0x85000, in my case, and debug shows that boot util looks for FW at other address:

00> I: dfu core > dfu_core_update_local_fw > header info >> size 338724, ver 1
00> D: writing magic; fa_id=5 off=0x78ff0 (0xfdff0)
00> D: writing swap_info; fa_id=5 off=0x78fd8 (0xfdfd8), swap_type=0x2 image_num=0x0
00> I: MCUBoot image upgrade scheduled. Reset device to apply
00> D: dfu core > dfu_core_update_local_fw > storing dfu request.

P.s. I can't enable RTT logging in MCUBoot to get log info at startup. I use next configs in mcuboot.conf :

CONFIG_LOG=y
CONFIG_LOG_MODE_MINIMAL=y # former CONFIG_MODE_MINIMAL
CONFIG_SERIAL=n
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_MODE_IMMEDIATE=y
CONFIG_UART_CONSOLE=n
CONFIG_RTT_CONSOLE=y

### Ensure Zephyr logging changes don't use more resources
CONFIG_LOG_DEFAULT_LEVEL=4
### Decrease footprint by ~4 KB in comparison to CBPRINTF_COMPLETE=y
CONFIG_CBPRINTF_NANO=y

CONFIG_BOOT_MAX_IMG_SECTORS=1024

and overlay definition at CmakeLists

if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")
    list(APPEND mcuboot_OVERLAY_CONFIG
            "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf"
            )
endif()

Tools:

1. nRF52840 custom board
2. NCS v1.6.1
3. Ubuntu
4. JLinkRTTViewer

[Amanda Hsieh]

Hi, 

Do you locate the mcuboot to the same address of the bootloader? If not, you can build with pm_static.yml. Then, run the following command to check the memory layout.  

$ west build -t rom_report // Ninja build target to display flash layout. 

Take a look at the example in this case. 

Regards,
Amanda

[ipshiv]

Good day!

I update NCS from NCS.

Steps:

1. Compile and flash firmware on clean nRF52 using flash target;
2. Update version in prj.conf and add small blinking loop in main;
3. Compile app_update.bin using merged.hex target;
4. Upload app_update.bin over mesh
5. Try to update and nothing.

I'll try pm_static

[ipshiv]

  flash_primary (0x100000 - 1024kB): 
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x79000 - 484kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x78e00 - 483kB)-+
| 0xc200: app (0x78e00 - 483kB)                   |
+-------------------------------------------------+
| 0x85000: mcuboot_secondary (0x79000 - 484kB)    |
| 0xfe000: settings_storage (0x2000 - 8kB)        |
+-------------------------------------------------+

  sram_primary (0x40000 - 256kB): 
+--------------------------------------------+
| 0x20000000: sram_primary (0x40000 - 256kB) |
+--------------------------------------------+

Looks fine

[ipshiv]

Why before update target mcuboot deletes last page?

		err = stream_flash_erase_page(dfu_target_stream_get_stream(),
					      MCUBOOT_SECONDARY_LAST_PAGE_ADDR);

[Amanda Hsieh]

Hi, 

The image trailer is stored there. With information about swap/copy status and the overall status of the image. So this erasing must be done to ensure status is set for the currently downloaded image. See https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.7.0/mcuboot/design.html#image-trailer 

The log looks like it's writing to the wrong address. We guess there must be a difference in the memory layout for the 2 versions.  Are the addresses the same for both builds?

-Amanda