Attachments (0)
Nordic Case Info
  • Case ID: 300262
Options

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

Fullscreen
1
2
3
4
5
6
7
8
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
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Result: Works!

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

Fullscreen
1
2
3
4
5
6
7
8
*** 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
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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

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).

  • 0

    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

  • 0 in reply to Sigurd Hellesvik

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

    Sure, here it is:

    smp_svr partitions.yml (Nordic's)

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    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
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Our DFU partitions.yml 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    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
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Our Application partitions.yml

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    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
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    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?

  • 0

    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

Terms of service