McuBoot doesn't switch to pending image

[Vagner Landskron]

Hello,

I've a "follow up" issue related to this ticket:  BL653 crashes when working with CONFIG_MCUMGR_SMP_BT & CONFIG_ESB

In an earlier state of our project, we've adopted the smp_svr application as our "DFU".

But during maturation of our project, we developed our own DFU.

Now, it happens that we have ~40 assembled units running smp_svr and we would like to switch by our DFU.

I perform the following steps:

1. Upload my new DFU image to the device OTA and switch slots (permanent)

Result: Works!

2. Now I upload our application (regular application) 

Result: Works!

3. Now I click on "Confirm" and switch slots 1 to 0

I: Swap type: none
writing swap_info; fa_id=5 off=0x39fd8 (0x7ffd8), swap_type=0x3 image_num=0x0func img_mgmt_state_read
func img_mgmt_state_flags, 0
func img_mgmt_impl_swap_type, 0
I: Swap type: perm
func img_mgmt_state_flags, 1
func img_mgmt_impl_swap_type, 0
I: Swap type: perm

Result: Works!

4. I reset my device and expect the Mcuboot to switch the image slots (to run my application)

*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
I: Jumping to the first image slot

Result: it still runs my DFU application instead of my regular application 

What could lead to such behavior? Any ideas on how to debug this?

Disclaimer: in case I flash my DFU Application first, I'm able to run my application, rollback to DFU, upgrade my application image as much as I want. It seems like the smp_svr puts my device's flash in an invalid state (in the slot it use to be).

[Sigurd Hellesvik]

Hi,

Are your partitions the same size before and after the DFU?

Can you upload build/partitions.yml from  both your old and your new project?

Regards,
Sigurd Hellesvik

[Vagner Landskron]

Humm, actually I didn't put any effort into this, everything is "default".

Sure, here it is:

smp_svr partitions.yml (Nordic's)

app:
  address: 0xc200
  end_address: 0x46000
  region: flash_primary
  size: 0x39e00
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0x46000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  sharers: 0x1
  size: 0x3a000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0x46000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x39e00
  span: *id002
mcuboot_secondary:
  address: 0x46000
  end_address: 0x80000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
    align_next: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x3a000
sram_primary:
  address: 0x20000000
  end_address: 0x20020000
  region: sram_primary
  size: 0x20000

Our DFU partitions.yml 

app:
  address: 0xc200
  end_address: 0x46000
  region: flash_primary
  size: 0x39e00
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0x46000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  sharers: 0x1
  size: 0x3a000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0x46000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x39e00
  span: *id002
mcuboot_secondary:
  address: 0x46000
  end_address: 0x80000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
    align_next: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x3a000
sram_primary:
  address: 0x20000000
  end_address: 0x20020000
  region: sram_primary
  size: 0x20000

Our Application partitions.yml

app:
  address: 0xc200
  end_address: 0x46000
  region: flash_primary
  size: 0x39e00
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0x46000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  sharers: 0x1
  size: 0x3a000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0x46000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x39e00
  span: *id002
mcuboot_secondary:
  address: 0x46000
  end_address: 0x80000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
    align_next: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x3a000
sram_primary:
  address: 0x20000000
  end_address: 0x20020000
  region: sram_primary
  size: 0x20000

Between Our DFU and Our Application, there are no differences.

But between Our DFU and smp_svr there is this small difference, could it be the cause?

[Sigurd Hellesvik]

Hi,

I am not sure why those would be in different order, but it just might interfere with stuff. Try to change it to be consistent and maybe it will behave differently?

Any ideas on how to debug this?

MCUboot runs mcuboot/boot/zephyr/main.c, which in calls do_boot from mcuboot/boot/bootutil/loader.c.
I suggest that you debug or add prints here to follow what is happening.

Regards,
Sigurd Hellesvik