Thanks Alvaro, this is great.

On 5 Jul 2019, at 6:32, Alvaro wrote:

I was able to figure out the issue that caused mcuboot to wipe the image
every time.
The newt app was using the wrong flag value so the app image showed up as
bootable: https://github.com/apache/mynewt-newt/pull/306

I also found a bug in mcuboot that prevents split images from working as
well: https://github.com/JuulLabs-OSS/mcuboot/pull/500

Cheers,

Alvaro

On Sat, Jun 29, 2019 at 6:57 AM Alvaro <apg8...@gmail.com> wrote:

TL;DR - Mcuboot seems to be erasing my app images in split configuration,
and I can't figure out why...(or what I'm doing wrong)

Hi All,

I'm trying to get split images working but having no luck. Currently, I'm
following these instructions:
http://mynewt.apache.org/latest/os/modules/split/split.html#image-upgrade-split
(With slight modifications to use mcumgr instead of newtmgr.

Here's my setup:
1x NRF52DK (pca10400) dev board
top-of-tree newt tool (build from source)
top-of-tree mcumgr (go get github.com/apache/mynewt-mcumgr-cli/mcumgr)
This repo has all the code: https://github.com/alvarop/split_test

I'm using mcuboot with target nrf52_boot
I'm using bleprph from apache-mynewt-nimble as my loader
I'm using splitty from apache-mynewt-core as my main app

First I load the booatloader with newt load nrf52_boot
I then create the split image with create-image split-nrf52dk 1.0.0
I then load the image with newt load split-nrf52dk

I query the images over BLE:
mcumgr image list -c mybleprph
Images:
 slot=0
    version: 1.0.0
    bootable: true
    flags: active confirmed
hash: 31a1b0568dffb840a30a361db1cf747ba63f97c141aef2ac18674744000f12fb
 slot=1
    version: 1.0.0
    bootable: true
    flags:
hash: f13c88e281e8b790e189b8db45abac25f86c19e6c85f8f56bfeec2ece349112a
Split status: N/A (0)

Right off the bat, the system never boots into the app image, it stays in
the loader. Maybe it's because it is marked as active.. ok.

I create a "new" image so we can differentiate with newt-dev create-image
split-nrf52dk 1.0.1
I upload the new image:
mcumgr image upload -c mybleprph
bin/targets/split-nrf52dk/app/apps/splitty/splitty.img

And confirm it is there:
mcumgr image list -c mybleprph
Images:
 slot=0
    version: 1.0.0
    bootable: true
    flags: active confirmed
hash: 31a1b0568dffb840a30a361db1cf747ba63f97c141aef2ac18674744000f12fb
 slot=1
    version: 1.0.1
    bootable: true
    flags:
hash: 45f5338c09eb5ea04729ef0092c3645876e7bd6a8ebf307a040780d9b50dea25
Split status: N/A (0)

I then want to test it and use:
mcumgr image test -c mybleprph
45f5338c09eb5ea04729ef0092c3645876e7bd6a8ebf307a040780d9b50dea25
Images:
 slot=0
    version: 1.0.0
    bootable: true
    flags: active confirmed
hash: 31a1b0568dffb840a30a361db1cf747ba63f97c141aef2ac18674744000f12fb
 slot=1
    version: 1.0.1
    bootable: true
    flags: pending
hash: 45f5338c09eb5ea04729ef0092c3645876e7bd6a8ebf307a040780d9b50dea25
Split status: N/A (0)

Now the new image in slot 1 is pending. Resetting should switch to it.
mcumgr reset -c mybleprph

When I check again, the image is gone:
mcumgr image list -c mybleprph
Images:
 slot=0
    version: 1.0.0
    bootable: true
    flags: active confirmed
hash: 31a1b0568dffb840a30a361db1cf747ba63f97c141aef2ac18674744000f12fb
Split status: N/A (0)

I have verified that the flash has been erased and that mcuboot did it. I want to check if there's anything obviously wrong with my procedure before
digging in deeper into mcuboot.

Thank you for your help,

Cheers,

Alvaro

Reply via email to