• State Verified Answer
  • Replies 4 replies
  • Subscribers 89 subscribers
  • Views 1114 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 305224
Options

Incorrect flash partitions used in mcuboot

esscriber

I am trying to build the sys_heap example with tfm and mcuboot with a very simple custom board based on the nrf9160dk_nrf9160 using NCS v2.2.0. But when I run it on my board, MCUboot is unable to find a bootable image. Some times the examples runs correctly, but most of the times it doesn't. The reason for mcuboot not finding a bootable image is because it is using the flash partitions defined in the device tree, but the memory report shows the correct flash partitions . I have determined this by editing get_flash_area_from_id in flash_map_priv.h (see both code blocks). I am not sure how to fix this issue, I have included my project.

static inline struct flash_area const *get_flash_area_from_id(int idx)
{
	for (int i = 0; i < flash_map_entries; i++) {
		printk ("flash_map_priv %02u -> (%02u/%02u): %08lx-%08lx (%08x) %s\n", idx, flash_map[i].fa_id, flash_map_entries, flash_map[i].fa_off, flash_map[i].fa_off + flash_map[i].fa_size, flash_map[i].fa_size, flash_map[i].fa_dev->name);
		if (flash_map[i].fa_id == idx) {
			return &flash_map[i];
		}
	}

	return NULL;
}

*** Booting Zephyr OS build v3.2.99-ncs1 ***
I: Starting bootloader
default flash_map 03 -> (00/07): 00000000-00010000 (00010000) flash-controller@39000
default flash_map 03 -> (01/07): 00010000-00050000 (00040000) flash-controller@39000
default flash_map 03 -> (02/07): 00050000-00080000 (00030000) flash-controller@39000
default flash_map 03 -> (03/07): 00080000-000c0000 (00040000) flash-controller@39000
default flash_map 09 -> (00/07): 00000000-00010000 (00010000) flash-controller@39000
default flash_map 09 -> (01/07): 00010000-00050000 (00040000) flash-controller@39000
default flash_map 09 -> (02/07): 00050000-00080000 (00030000) flash-controller@39000
default flash_map 09 -> (03/07): 00080000-000c0000 (00040000) flash-controller@39000
default flash_map 09 -> (04/07): 000c0000-000f0000 (00030000) flash-controller@39000
default flash_map 09 -> (05/07): 000f0000-000fa000 (0000a000) flash-controller@39000
default flash_map 09 -> (06/07): 000fa000-00100000 (00006000) flash-controller@39000
default flash_map 03 -> (00/07): 00000000-00010000 (00010000) flash-controller@39000
default flash_map 03 -> (01/07): 00010000-00050000 (00040000) flash-controller@39000
default flash_map 03 -> (02/07): 00050000-00080000 (00030000) flash-controller@39000
default flash_map 03 -> (03/07): 00080000-000c0000 (00040000) flash-controller@39000
default flash_map 09 -> (00/07): 00000000-00010000 (00010000) flash-controller@39000
default flash_map 09 -> (01/07): 00010000-00050000 (00040000) flash-controller@39000
default flash_map 09 -> (02/07): 00050000-00080000 (00030000) flash-controller@39000
default flash_map 09 -> (03/07): 00080000-000c0000 (00040000) flash-controller@39000
default flash_map 09 -> (04/07): 000c0000-000f0000 (00030000) flash-controller@39000
default flash_map 09 -> (05/07): 000f0000-000fa000 (0000a000) flash-controller@39000
default flash_map 09 -> (06/07): 000fa000-00100000 (00006000) flash-controller@39000
W: Failed reading sectors; BOOT_MAX_IMG_SECTORS=128 - too small?
default flash_map 03 -> (00/07): 00000000-00010000 (00010000) flash-controller@39000
default flash_map 03 -> (01/07): 00010000-00050000 (00040000) flash-controller@39000
default flash_map 03 -> (02/07): 00050000-00080000 (00030000) flash-controller@39000
default flash_map 03 -> (03/07): 00080000-000c0000 (00040000) flash-controller@39000
default flash_map 09 -> (00/07): 00000000-00010000 (00010000) flash-controller@39000
default flash_map 09 -> (01/07): 00010000-00050000 (00040000) flash-controller@39000
default flash_map 09 -> (02/07): 00050000-00080000 (00030000) flash-controller@39000
default flash_map 09 -> (03/07): 00080000-000c0000 (00040000) flash-controller@39000
default flash_map 09 -> (04/07): 000c0000-000f0000 (00030000) flash-controller@39000
default flash_map 09 -> (05/07): 000f0000-000fa000 (0000a000) flash-controller@39000
default flash_map 09 -> (06/07): 000fa000-00100000 (00006000) flash-controller@39000
W: Cannot upgrade: not a compatible amount of sectors
default flash_map 03 -> (00/07): 00000000-00010000 (00010000) flash-controller@39000
default flash_map 03 -> (01/07): 00010000-00050000 (00040000) flash-controller@39000
default flash_map 03 -> (02/07): 00050000-00080000 (00030000) flash-controller@39000
default flash_map 03 -> (03/07): 00080000-000c0000 (00040000) flash-controller@39000
default flash_map 03 -> (00/07): 00000000-00010000 (00010000) flash-controller@39000
default flash_map 03 -> (01/07): 00010000-00050000 (00040000) flash-controller@39000
default flash_map 03 -> (02/07): 00050000-00080000 (00030000) flash-controller@39000
default flash_map 03 -> (03/07): 00080000-000c0000 (00040000) flash-controller@39000
E: Unable to find bootable image

1157.sys_heap.zip

Parents
  • 0

    Hi,

     

    I am trying to build the sys_heap example with tfm and mcuboot with a very simple custom board based on the nrf9160dk_nrf9160 using NCS v2.2.0. But when I run it on my board, MCUboot is unable to find a bootable image. Some times the examples runs correctly, but most of the times it doesn't

    Could you elaborate on how you reproduce this?

    Do you for instance first flash the "merged.hex" file, then enter debug mode?

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Hi,

    I perform a pristine build and flash the merged.hex file to the board, without going into debug mode / clicking debug in vs code. The output is send via uart0.

    In between builds I am changing the prj.conf and/or mcuboot.conf to try and get it to run.

    I hope this answers your question

  • +1 in reply to esscriber

    Hi,

     

    It could be that you should remove this line:

    list(APPEND mcuboot_OVERLAY_CONFIG ${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf)

    And rather place the mcuboot.conf file in the path "child_image/mcuboot.conf" instead.

     

    esscriber said:

    In between builds I am changing the prj.conf and/or mcuboot.conf to try and get it to run.

    You should not have to run pristine each time. The build system, if child_image/mcuboot.conf is used, should be able to pick up this change.

    The only time you should regenerate your project is when you add new files, like boards/$board.conf or .overlay.

     

    Kind regards,

    Håkon

Reply
  • +1 in reply to esscriber

    Hi,

     

    It could be that you should remove this line:

    list(APPEND mcuboot_OVERLAY_CONFIG ${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf)

    And rather place the mcuboot.conf file in the path "child_image/mcuboot.conf" instead.

     

    esscriber said:

    In between builds I am changing the prj.conf and/or mcuboot.conf to try and get it to run.

    You should not have to run pristine each time. The build system, if child_image/mcuboot.conf is used, should be able to pick up this change.

    The only time you should regenerate your project is when you add new files, like boards/$board.conf or .overlay.

     

    Kind regards,

    Håkon

Children
Related