Mcuboot reboots back to old image

[Christoffer Brask]

Hi,

I work on a project that required a sector in flash to store some information hence I changed the partition in the pm_static.yml file and the dts file (although I guess this has no effect when using MCUboot).

The problems I have encountered is the following:

• Flashing a firmware (A) that uses the new partition, it is not possible to downgrade to a firmware (B) using the old partition. The downgrade is succesful but the system reboots after a few seconds and reverts the image back to (A). 
• Flashing a firmware (B) that uses the old partition, it is possible to upgrade and stay on a firmware (A) that uses the new partition. Doing another upgrade to a firmware (C) that uses the same "new" partition reverts the image back to firmware (A).

I'm calling boot_write_img_confirmed at startup and has not seen any firmware reverts before changing the partition.

    

[Simon]

Could you upload the complete generated pm output you get after buliding the old (B), and the new (A) image? You can find the output in <application>\build\partitions.yml.

[Christoffer Brask]

(A)

EMPTY_0:
  address: 0xf8000
  end_address: 0xf9000
  placement:
    after:
    - mcuboot_secondary
  region: flash_primary
  size: 0x1000
app:
  address: 0xc200
  end_address: 0x82000
  region: flash_primary
  size: 0x75e00
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: 0x82000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  sharers: 0x1
  size: 0x76000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0x82000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x75e00
  span: *id002
mcuboot_secondary:
  address: 0x82000
  end_address: 0xf8000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
    align_next: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x76000
settings_storage:
  address: 0xf9000
  end_address: 0xfc000
  placement:
    before:
    - uptime_storage
  region: flash_primary
  size: 0x3000
sram_primary:
  address: 0x20000000
  end_address: 0x20040000
  region: sram_primary
  size: 0x40000
uptime_storage:
  address: 0xfc000
  end_address: 0xfd000
  placement:
    before:
    - user_storage
  region: flash_primary
  size: 0x1000
user_storage:
  address: 0xfd000
  end_address: 0x100000
  placement:
    before:
    - end
  region: flash_primary
  size: 0x3000

     

(B)

 

app:
  address: 0xc200
  end_address: 0x83000
  region: flash_primary
  size: 0x76e00
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: 0x83000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  sharers: 0x1
  size: 0x77000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0x83000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x76e00
  span: *id002
mcuboot_secondary:
  address: 0x83000
  end_address: 0xfa000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
    align_next: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x77000
settings_storage:
  address: 0xfa000
  end_address: 0xfd000
  placement:
    before:
    - user_storage
  region: flash_primary
  size: 0x3000
sram_primary:
  address: 0x20000000
  end_address: 0x20040000
  region: sram_primary
  size: 0x40000
user_storage:
  address: 0xfd000
  end_address: 0x100000
  placement:
    before:
    - end
  region: flash_primary
  size: 0x3000

                                                                                       

[Simon]

It is not recommended to change the partitions between updates, since mcuboot will still use the old partitions sizes and positions. I can see that the allocated size for the application image is larger for the new build (A) compared to the old build (B) (you can see that mcuboot_primary/secondary has the size 0x76000 in A, and the size 0x77000 in B). Maybe that would cause some issues? I can also see that some other partitions has changed start position.

However, it is hard to say what's causing it.

Flashing a firmware (A) that uses the new partition, it is not possible to downgrade to a firmware (B) using the old partition. The downgrade is succesful but the system reboots after a few seconds and reverts the image back to (A). 

My understanding of the above statement is that MCUboot is able to validate image B and swap it with A, but when booting into B it reboots and swaps back.

Maybe a fault is happening during the init phase, before image B is able to run boot_write_img_confirmed() (does not confirm itself), and due to CONFIG_RESET_ON_FATAL_ERROR=y, the program resets, swaps back and boots into image A (since B is not confirmed). Could enable UART or RTT logging and set CONFIG_LOG=y in image B and see if you get any info about why it resets?

Best regards,

Simon