Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve support for DISCO_L475VG_IOT01A #13

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Improve support for DISCO_L475VG_IOT01A #13

Show file tree
Hide file tree
Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
b302a87
Generate hex image for all targets by default
LDong-Arm Aug 24, 2021
7f6980a
Do not enable mcuboot.read-granularity on DISCO_L475VG_IOT01A
LDong-Arm Aug 24, 2021
f9b42e4
Update Mbed OS to 6.14.0
LDong-Arm Aug 24, 2021
4157253
Update logs in README to support update confirmation/rejection
LDong-Arm Aug 24, 2021
d1709f2
Remove redundant overrides of qspif.QSPI_MIN_PROG_SIZE
LDong-Arm Aug 25, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 22 additions & 32 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -132,6 +132,8 @@ You should also install the python package `intelhex` if it is not already insta

This python package includes several utility scripts for working with binaries and .hex files.

By default, the demo application and bootloader are built as hex files to support flashing multiple images to different addresses. Some targets need to have the latest debug interface firmwares to support this, for example ST-LINK's firmware upgrader can be found [here](https://www.st.com/en/development-tools/stsw-link007.html). If your target does not support hex images, a single bin image with everything merged together can be used instead as will be described in [Merging it all together](#Merging-it-all-together) below.

### Creating the signing keys and building the bootloader

This section will only cover steps specific to setting up this project with a signing key pair and signing a main application binary. For more advanced use cases and information, such as using alternative signing algorithms to rsa-2048, see the [mcuboot documentation on Image Signing](https://github.com/mcu-tools/mcuboot/blob/master/docs/signed_images.md#image-signing).
Expand Down Expand Up @@ -236,7 +238,9 @@ Other toolchains will have a similar utility to perform this step.

### Merging it all together

To be able to drag-and-drop program the whole demo together, it is necessary to merge all the hex files we created in the last steps together.
Usually, if your target supports hex files, you can drag-and-drop one image at a time (waiting for each to finish) to program them into their respective locations.

If your target doesn't support hex files or performs a whole chip erase upon every drag-and-drop action, it is necessary to merge all the hex files we created in the last steps together.

At this step, you should have created three hex files:
- mbed-mcuboot-demo.hex (the bootloader)
Expand Down Expand Up @@ -276,15 +280,16 @@ Once your target has been programmed, open a serial terminal to view the debug o
```
-- Terminal on /dev/ttyACM1 - 9600,8,N,1 ---
[INFO][BL]: Starting MCUboot
[INFO][MCUb]: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
[INFO][MCUb]: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INFO][MCUb]: Boot source: none
[INFO][MCUb]: Swap type: none

<Potentially random data from the UART>

[INFO][BL]: Booting firmware image at 0x21000

<Potentially random data from the UART>

[INFO][main]: Hello version 1.2.3+4
<Potentially random data from the UART>

[INFO][main]: Regular boot
[INFO][main]: > Press button to erase secondary slot

```
Expand Down Expand Up @@ -319,8 +324,6 @@ This causes the bootloader to check the secondary slot for a valid update binary
You should see output similar to the following:

```
[DBG ][MCUb]: writing magic; fa_id=1 off=0xbfff0 (0xbfff0)
[DBG ][MCUb]: writing swap_info; fa_id=1 off=0xbffd8 (0xbffd8), swap_type=0x2 image_num=0x0
[INFO][main]: > Secondary image pending, reboot to update
```

Expand All @@ -330,39 +333,26 @@ Now all you need to do to perform the update is reset your Mbed board! The mcubo

```
[INFO][BL]: Starting MCUboot
[INFO][MCUb]: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INFO][MCUb]: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INFO][MCUb]: Boot source: primary slot
[INFO][MCUb]: Swap type: test
[DBG ][MCUb]: erasing scratch area
[DBG ][MCUb]: initializing status; fa_id=2
[DBG ][MCUb]: writing swap_info; fa_id=2 off=0x1ffd8 (0xfffd8), swap_type=0x2 image_num=0x0
[DBG ][MCUb]: writing swap_size; fa_id=2 off=0x1ffd0 (0xfffd0)
[DBG ][MCUb]: writing magic; fa_id=2 off=0x1fff0 (0xffff0)
[DBG ][MCUb]: erasing trailer; fa_id=0
[DBG ][MCUb]: initializing status; fa_id=0
[DBG ][MCUb]: writing swap_info; fa_id=0 off=0xbffd8 (0xdffd8), swap_type=0x2 image_num=0x0
[DBG ][MCUb]: writing swap_size; fa_id=0 off=0xbffd0 (0xdffd0)
[DBG ][MCUb]: writing magic; fa_id=0 off=0xbfff0 (0xdfff0)
[DBG ][MCUb]: erasing trailer; fa_id=1
[DBG ][MCUb]: writing copy_done; fa_id=0 off=0xbffe0 (0xdffe0)

<Potentially random data from the UART>

[INFO][BL]: Booting firmware image at 0x21000

<Potentially random data from the UART>

[INFO][main]: Boot confirmed
[INFO][main]: Hello version 1.2.3+5
[INFO][main]: > Press button to erase secondary slot
[INFO][main]: Firmware update applied successfully
[INFO][main]: Press the button to confirm, or reboot to revert the update
```

Notice that the reported version number has changed! The update was performed successfully.

**Note:** After an update is performed, the new application must mark itself as "okay" to the mcuboot bootloader. If this does not occur, mcuboot will revert the update upon the next reboot (if configured to do so).

The blinky application in this demo always does this at startup:
To make the update as "okay", press the button as instructed. This causes the application to call
`boot_set_confirmed()`.

Now you should see:

```
int ret = boot_set_confirmed();
[INFO][main]: Current firmware set as confirmed
```

In real world situations, your application should run a self test routine to ensure it can receive updates in the future (eg: the UART software works as expected, the BLE stack initializes successfully, etc).
**Note:** In real world situations, your application should run a self test routine to ensure it can receive updates in the future (eg: the UART software works as expected, the BLE stack initializes successfully, etc).
2 changes: 1 addition & 1 deletion mbed-os.lib
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1 +1 @@
https://github.com/ARMmbed/mbed-os/#8ef0a435b2356f8159dea8e427b2935d177309f8
https://github.com/ARMmbed/mbed-os/#3377f083b3a6bd7a1b45ed2cea5cf083b9007527
5 changes: 2 additions & 3 deletions mbed_app.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,7 @@
"*": {
"target.restrict_size": "0x20000",
"target.c_lib": "small",
"target.OUTPUT_EXT": "hex",
"mcuboot.log-level": "MCUBOOT_LOG_LEVEL_DEBUG",
"mbed-trace.enable": true,
"mbed-trace.fea-ipv6": false
Expand Down Expand Up @@ -41,9 +42,7 @@
"mcuboot.slot-size": "0xC0000",
"mcuboot.scratch-address": "0x80E0000",
"mcuboot.scratch-size": "0x20000",
"mcuboot.max-img-sectors": "0x180",
"mcuboot.read-granularity": 1,
"qspif.QSPI_MIN_PROG_SIZE": 1
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There doesn't seem to be a default for this in targets.json. Could the absence of this cause bd r/w to fail?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default for all targets is defined to be 1 here: https://github.com/ARMmbed/mbed-os/blob/f6e165febec105c042137a4d1bf663a58968aac8/storage/blockdevice/COMPONENT_QSPIF/mbed_lib.json#L21
So DISCO_L475VG_IOT01A has it set to 1.

Also, we can remove the override for EP_AGORA and NRF52840_DK too, because they both inherit MCU_NRF52840 which is already set to 4: https://github.com/ARMmbed/mbed-os/blob/f6e165febec105c042137a4d1bf663a58968aac8/storage/blockdevice/COMPONENT_QSPIF/mbed_lib.json#L40

Copy link
Contributor Author

@LDong-Arm LDong-Arm Aug 25, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a commit to further clean this up for MCU_NRF52840

"mcuboot.max-img-sectors": "0x180"
}
}
}