Skip to content

Commit e39ba1a

Browse files
committed
boards: stm32h750b_dk: introduce board variant for apps in ext Flash
Introduce a board variant for storing an app in external QSPI NOR Flash and chainloading it with MCUboot (placed in internal Flash) to be executed in place (uses Mcuboot's Single App mode, set via Sysbuild, by default). The new variant requires on MCUboot app side: a board/SoC DT overlay to set the internal Flash & Flash controller as the chosen 'zephyr,flash' & 'zephyr,flash-controller', and CONFIG_STM32_MEMMAP=y (this was upstreamed to MCUboot.) Change external Flash memory attribute "zephyr,memory-attr" to DT_MEM_ARM_MPU_FLASH, since ATTR_MPU_IO (corresponds to "DEVICE_NON_SHAREABLE & P_RW_U_NA") is actually for memory-mapped devices (with registers...) and was causing access issues with apps like LVGL that would freeze the target. Also, change the size of the external flash "zephyr,memory-region" node, since we only need to define accesss rights to the memory space actually used by the external flash chips, not the total addresssable QSPI memory. The 2nd QSPI NOR contoller node was removed, since it does not reflect the actual hardware layout, that has only one controller and the 2 NOR flash chips are connected to it in parallel with a shift register. Signed-off-by: Abderrahmane JARMOUNI <git@jarmouni.me>
1 parent 31abf23 commit e39ba1a

11 files changed

+497
-290
lines changed
Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
# SPDX-FileCopyrightText: Copyright The Zephyr Project Contributors
2+
# SPDX-License-Identifier: Apache-2.0
3+
4+
if BOARD_STM32H750B_DK_STM32H750XX_EXT_FLASH_APP
5+
6+
choice BOOTLOADER
7+
default BOOTLOADER_MCUBOOT
8+
endchoice
9+
10+
choice BOOT_SIGNATURE_TYPE
11+
default BOOT_SIGNATURE_TYPE_NONE
12+
endchoice
13+
14+
choice MCUBOOT_MODE
15+
default MCUBOOT_MODE_SINGLE_APP
16+
endchoice
17+
18+
endif # BOARD_STM32H750B_DK_STM32H750XX_EXT_FLASH_APP

boards/st/stm32h750b_dk/board.cmake

Lines changed: 3 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,10 @@
1+
# SPDX-FileCopyrightText: Copyright The Zephyr Project Contributors
12
# SPDX-License-Identifier: Apache-2.0
23

34
# keep first
4-
if(CONFIG_STM32_MEMMAP)
55
board_runner_args(stm32cubeprogrammer "--port=swd" "--reset-mode=hw")
6-
board_runner_args(stm32cubeprogrammer "--extload=MT25TL01G_STM32H750B-DISCO.stldr")
7-
else()
8-
board_runner_args(stm32cubeprogrammer "--port=swd" "--reset-mode=hw" )
6+
if(CONFIG_STM32_MEMMAP OR CONFIG_BOOTLOADER_MCUBOOT)
7+
board_runner_args(stm32cubeprogrammer "--extload=MT25TL01G_STM32H750B-DISCO.stldr")
98
endif()
109

1110
board_runner_args(jlink "--device=STM32H735IG" "--speed=4000")

boards/st/stm32h750b_dk/board.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -4,3 +4,5 @@ board:
44
vendor: st
55
socs:
66
- name: stm32h750xx
7+
variants:
8+
- name: ext_flash_app

boards/st/stm32h750b_dk/doc/index.rst

Lines changed: 104 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -72,25 +72,26 @@ Programming and Debugging
7272
STM32H750B Discovery kit includes an ST-LINK-V3E embedded debug tool interface.
7373
This probe allows flashing and debugging the board using various tools.
7474

75-
See :ref:`build_an_application` for more information about application builds.
76-
77-
78-
Flashing
79-
========
80-
8175
The board is configured to be flashed using west `STM32CubeProgrammer`_ runner,
8276
so its :ref:`installation <stm32cubeprog-flash-host-tools>` is required.
8377

84-
Alternatively, OpenOCD or JLink can also be used to flash the board using
78+
Alternatively, OpenOCD or JLink can also be used to write app to the SoC Flash using
8579
the ``--runner`` (or ``-r``) option:
8680

8781
.. code-block:: console
8882
8983
$ west flash --runner openocd
9084
$ west flash --runner jlink
9185
92-
Flashing an application to STM32H750B_DK
93-
----------------------------------------
86+
Application in SoC Flash
87+
========================
88+
89+
Here is an example for how to build and flash the :zephyr:code-sample:`hello_world` application.
90+
91+
.. zephyr-app-commands::
92+
:zephyr-app: samples/hello_world
93+
:board: stm32h750b_dk
94+
:goals: build flash
9495

9596
Connect the STM32H750B-DK to your host computer using the ST-LINK
9697
USB port, then run a serial host program to connect with the board. For example:
@@ -99,23 +100,18 @@ USB port, then run a serial host program to connect with the board. For example:
99100
100101
$ minicom -b 115200 -D /dev/ttyACM0
101102
102-
You can then build and flash applications in the usual way.
103-
Here is an example for the :zephyr:code-sample:`hello_world` application.
104-
105-
.. zephyr-app-commands::
106-
:zephyr-app: samples/hello_world
107-
:board: stm32h750b_dk
108-
:goals: build flash
109-
110103
You should see the following message in the serial host program:
111104

112105
.. code-block:: console
113106
114107
$ Hello World! stm32h750b_dk
115108
109+
If the application size is too big to fit in SoC Flash,
110+
Zephyr :ref:`Code and Data Relocation <code_data_relocation>` can be used to relocate
111+
the non-critical and big parts of the application to external Flash.
116112

117113
Debugging
118-
=========
114+
---------
119115

120116
You can debug an application in the usual way. Here is an example for the
121117
:zephyr:code-sample:`hello_world` application.
@@ -125,6 +121,90 @@ You can debug an application in the usual way. Here is an example for the
125121
:board: stm32h750b_dk
126122
:goals: debug
127123

124+
Application in External Flash
125+
=============================
126+
127+
Because of the limited amount of SoC Flash (128KB), you may want to store the application
128+
in external QSPI Flash instead, and run it from there. In that case, the MCUboot bootloader
129+
is needed to chainload the application. A dedicate board variant, ``ext_flash_app``, was created
130+
for this usecase.
131+
132+
:ref:`sysbuild` makes it possible to build and flash all necessary images needed to run a user application
133+
from external Flash.
134+
135+
The following example shows how to build :zephyr:code-sample:`hello_world` with Sysbuild enabled:
136+
137+
.. zephyr-app-commands::
138+
:tool: west
139+
:zephyr-app: samples/hello_world
140+
:board: stm32h750b_dk/stm32h750xx/ext_flash_app
141+
:goals: build
142+
:west-args: --sysbuild
143+
144+
By default, Sysbuild creates MCUboot and user application images.
145+
146+
Build directory structure created by Sysbuild is different from traditional
147+
Zephyr build. Output is structured by the domain subdirectories:
148+
149+
.. code-block::
150+
151+
build/
152+
├── hello_world
153+
| └── zephyr
154+
│ ├── zephyr.elf
155+
│ ├── zephyr.hex
156+
│ ├── zephyr.bin
157+
│ ├── zephyr.signed.bin
158+
│ └── zephyr.signed.hex
159+
├── mcuboot
160+
│ └── zephyr
161+
│ ├── zephyr.elf
162+
│ ├── zephyr.hex
163+
│ └── zephyr.bin
164+
└── domains.yaml
165+
166+
.. note::
167+
168+
With ``--sysbuild`` option, MCUboot will be re-built every time the pristine build is used,
169+
but only needs to be flashed once if none of the MCUboot configs are changed.
170+
171+
For more information about the system build please read the :ref:`sysbuild` documentation.
172+
173+
Both MCUboot and user application images can be flashed by running:
174+
175+
.. code-block:: console
176+
177+
$ west flash
178+
179+
You should see the following message in the serial host program:
180+
181+
.. code-block:: console
182+
183+
*** Booting MCUboot v2.2.0-173-gb192716c969a ***
184+
*** Using Zephyr OS build v4.2.0-6260-gf798b3205e95 ***
185+
I: Starting bootloader
186+
I: Bootloader chainload address offset: 0x0
187+
I: Image version: v0.0.0
188+
I: Jumping to the first image slot
189+
*** Booting Zephyr OS build v4.2.0-6260-gf798b3205e95 ***
190+
Hello World! stm32h750b_dk/stm32h750xx/ext_flash_app
191+
192+
To only flash the user application in the subsequent builds, Use:
193+
194+
.. code-block:: console
195+
196+
$ west flash --domain hello_world
197+
198+
With the default configuration, the board uses MCUboot's Single App mode, which means
199+
the bootloader only boots the application image placed in slot0_partition and does
200+
not care about other slots.
201+
202+
To get more information about the different MCUboot operating modes and how they are related
203+
to Flash memory partition, and to learn how to perform application upgrade, refer
204+
to `MCUboot design`_.
205+
Also, to learn more about how to secure the app images stored in external Flash, refer
206+
to `MCUboot Encryption`_.
207+
128208

129209
.. _STM32H750B-DK website:
130210
https://www.st.com/en/evaluation-tools/stm32h750b-dk.html
@@ -140,3 +220,9 @@ You can debug an application in the usual way. Here is an example for the
140220

141221
.. _STM32CubeProgrammer:
142222
https://www.st.com/en/development-tools/stm32cubeprog.html
223+
224+
.. _MCUboot design:
225+
https://docs.mcuboot.com/design.html
226+
227+
.. _MCUboot Encryption:
228+
https://docs.mcuboot.com/encrypted_images.html

0 commit comments

Comments
 (0)