Skip to content

Get NUCLEO_H743ZI2 working with mcuboot #4

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

Merged
merged 2 commits into from
Jan 5, 2025
Merged

Get NUCLEO_H743ZI2 working with mcuboot #4

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3747c62
Get NUCLEO_H743ZI2 working
multiplemonomials Jan 5, 2025
8a00092
Remove README section that is apparently wrong
multiplemonomials Jan 5, 2025
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
4 changes: 1 addition & 3 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,9 +34,7 @@ The application header info section is at the beginning of the "primary memory s

When deciding what to boot/update, the mcuboot bootloader looks at an installed application's header info, which is a special struct prepended to the application binary. It uses this header info to validate that there is a bootable image installed in the "slot".

By default, this header is configured to be 4kB in size. This can be adjusted using the configuration parameter `mcuboot.header_size`.

**However,** due to the way the FlashIAP block device currently works while erasing, the header_size should be configured to be the size of an erase sector (4kB in the case of an nRF52840). Erasing using the FlashIAPBlockDevice only works if the given address is erase-sector aligned! On the other hand, there is a hard upper limit of `< 65536` enforced by imgtool script. This needs to be carefully taken into consideration when choosing a MCU. Because a erase-sector of size >=4KB <64KB may actually not be available between the end of bootloader and start of primary application. For example, STM32F767/9xGx series MCU with dual bank enabled cannot satisfy this constraint.
By default, this header is configured to be 4kB in size. This can be adjusted using the configuration parameter `mcuboot.header_size`.

This header is prepended to the application binary during the signing process (explained later).

Expand Down
2 changes: 1 addition & 1 deletion mbed-os
Open in desktop
Submodule mbed-os updated 3 files
+3 −0 targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT105x/TARGET_EVK/PinNames.h
+2 −2 targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT105x/device/TOOLCHAIN_GCC_ARM/MIMXRT1052xxxxx.ld
+1 −1 targets/upload_method_cfg/MIMXRT1060_EVK.cmake
7 changes: 4 additions & 3 deletions mbed_app.json5
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -124,16 +124,17 @@

// Since STM32H743 boards have no external block device, keep everything in the MCU flash.
"app.secondary-slot-in-flash": true,
"app.secondary-slot-flash-start-addr": "0x100000",
"app.secondary-slot-flash-start-addr": "0x08100000",

// Slot size can be as big as 896k, since we need to reserve the first flash sector for the bootloader
// and the last flash sector for scratch space
"mcuboot.primary-slot-address": "0x20000",
"mcuboot.primary-slot-address": "0x08020000",
"mcuboot.max-img-sectors": "7", // 7 flash sectors per slot
"mcuboot.slot-size": "0xE0000",
"mcuboot.flash-block-size": 32, // Flash program size is 32

// STM32H7 flash sector size is 128k, so we need to make the scratch region at least that big
"mcuboot.scratch-address": "0x1E0000",
"mcuboot.scratch-address": "0x081E0000",
"mcuboot.scratch-size": "0x20000"

},
Expand Down
Loading