README.rst
1:orphan:
2
3.. zephyr:code-sample:: smp-svr
4 :name: SMP server
5
6 Implement a Simple Management Protocol (SMP) server.
7
8Overview
9********
10
11This sample application implements a Simple Management Protocol (SMP) server.
12SMP is a basic transfer encoding for use with the MCUmgr management protocol.
13For more information about MCUmgr and SMP, please see :ref:`device_mgmt`.
14
15This sample application supports the following mcumgr transports by default:
16
17 * Shell
18 * Bluetooth
19 * UDP
20
21``smp_svr`` enables support for the following command groups:
22
23 * ``fs_mgmt``
24 * ``img_mgmt``
25 * ``os_mgmt``
26 * ``stat_mgmt``
27 * ``shell_mgmt``
28
29Caveats
30*******
31
32* The MCUboot bootloader is required for ``img_mgmt`` to function
33 properly. More information about the Device Firmware Upgrade subsystem and
34 MCUboot can be found in :ref:`mcuboot`.
35
36Prerequisites
37*************
38
39Use of a tool
40=============
41
42To interact remotely with the management subsystem on a device, a tool is required to interact with
43it. There are various tools available which are listed on the :ref:`mcumgr_tools_libraries` page
44of the Management subsystem documentation.
45
46Building a BLE Controller
47=========================
48
49.. note::
50 This section is only relevant for Linux users
51
52If you want to try out Device Firmware Upgrade (DFU) over the air using
53Bluetooth Low Energy (BLE) and do not have a built-in or pluggable BLE radio,
54you can build one and use it following the instructions in
55:ref:`bluetooth-hci-uart-bluez`.
56
57Building and flashing MCUboot
58*****************************
59
60The below steps describe how to build and run the MCUboot bootloader.
61Detailed instructions can be found in the :ref:`mcuboot` documentation page.
62
63The Zephyr port of MCUboot is essentially a normal Zephyr application, which means that
64it can be built and flashed like normal using ``west``, like so:
65
66.. code-block:: console
67
68 west build -b <board> -d build_mcuboot bootloader/mcuboot/boot/zephyr
69 west flash -d build_mcuboot
70
71Substitute <board> for one of the boards supported by the sample, see
72:file:`sample.yaml`.
73
74.. _smp_svr_sample_build:
75
76Building the sample application
77*******************************
78
79The below steps describe how to build and run the ``smp_svr`` sample in
80Zephyr. The ``smp_svr`` sample comes in different flavours.
81
82.. tabs::
83
84 .. group-tab:: Bluetooth
85
86 To build the bluetooth sample:
87
88 .. code-block:: console
89
90 west build \
91 -b nrf52dk/nrf52832 \
92 samples/subsys/mgmt/mcumgr/smp_svr \
93 -- \
94 -DEXTRA_CONF_FILE=overlay-bt.conf
95
96 .. group-tab:: Serial
97
98 To build the serial sample with file-system and shell management support:
99
100 .. code-block:: console
101
102 west build \
103 -b frdm_k64f \
104 samples/subsys/mgmt/mcumgr/smp_svr \
105 -- \
106 -DEXTRA_CONF_FILE='overlay-serial.conf;overlay-fs.conf;overlay-shell-mgmt.conf'
107
108 .. group-tab:: USB CDC_ACM
109
110 To build the serial sample with USB CDC_ACM backend:
111
112 .. code-block:: console
113
114 west build \
115 -b nrf52840dk/nrf52840 \
116 samples/subsys/mgmt/mcumgr/smp_svr \
117 -- \
118 -DEXTRA_CONF_FILE=overlay-cdc.conf \
119 -DDTC_OVERLAY_FILE=usb.overlay
120
121 .. group-tab:: Shell
122
123 To build the shell sample:
124
125 .. code-block:: console
126
127 west build \
128 -b frdm_k64f \
129 samples/subsys/mgmt/mcumgr/smp_svr \
130 -- \
131 -DEXTRA_CONF_FILE='overlay-shell.conf'
132
133 .. group-tab:: UDP
134
135 The UDP transport for SMP supports both IPv4 and IPv6.
136 In the sample, both IPv4 and IPv6 are enabled, but they can be
137 enabled and disabled separately.
138
139 To build the UDP sample:
140
141 .. code-block:: console
142
143 west build \
144 -b frdm_k64f \
145 samples/subsys/mgmt/mcumgr/smp_svr \
146 -- \
147 -DEXTRA_CONF_FILE=overlay-udp.conf
148
149.. _smp_svr_sample_sign:
150
151Signing the sample image
152************************
153
154A key feature of MCUboot is that images must be signed before they can be successfully
155uploaded and run on a target. To sign images, the MCUboot tool :file:`imgtool` can be used.
156
157To sign the sample image built in the previous step:
158
159.. code-block:: console
160
161 west sign -t imgtool -- --key bootloader/mcuboot/root-rsa-2048.pem
162
163The above command creates an image file called :file:`zephyr.signed.bin` in the
164build directory.
165
166For more information on image signing and ``west sign``, see the :ref:`west-sign`
167documentation.
168
169Flashing the sample image
170*************************
171
172Upload the :file:`zephyr.signed.bin` file from the previous to image slot-0 of your
173board. See :ref:`flash_map_api` for details on flash partitioning.
174
175To upload the initial image file to an empty slot-0, use ``west flash`` like normal.
176``west flash`` will automatically detect slot-0 address and confirm the image.
177
178.. code-block:: console
179
180 west flash --bin-file build/zephyr/zephyr.signed.bin
181
182The *signed* image file needs to be used specifically, otherwise the non-signed version
183will be used and the image won't be runnable.
184
185Sample image: hello world!
186==========================
187
188The ``smp_svr`` app is ready to run. Just reset your board and test the app
189with your choice of tool's ``echo`` functionality, which will
190send a string to the remote target device and have it echo it back.
191
192J-Link Virtual MSD Interaction Note
193***********************************
194
195On boards where a J-Link OB is present which has both CDC and MSC (virtual Mass
196Storage Device, also known as drag-and-drop) support, the MSD functionality can
197prevent mcumgr commands over the CDC UART port from working due to how USB
198endpoints are configured in the J-Link firmware (for example on the Nordic
199``nrf52840dk``) because of limiting the maximum packet size (most likely to occur
200when using image management commands for updating firmware). This issue can be
201resolved by disabling MSD functionality on the J-Link device, follow the
202instructions on :ref:`nordic_segger_msd` to disable MSD support.
203
204Device Firmware Upgrade (DFU)
205*****************************
206
207Now that the SMP server is running on your board and you are able to communicate
208with it using :file:`mcumgr`, you might want to test what is commonly called
209"OTA DFU", or Over-The-Air Device Firmware Upgrade. This works for both BT and UDP.
210
211The general sequence of a DFU process is as follows:
212
213* Build an MCUboot enabled application, see :ref:`smp_svr_sample_build`
214* Sign the application image, see :ref:`smp_svr_sample_sign`
215* Upload the signed image using :file:`mcumgr`
216* Listing the images on the device using :file:`mcumgr`
217* Mark the uploaded image for testing using :file:`mcumgr`
218* Reset the device remotely using :file:`mcumgr`
219* Confirm the uploaded image using :file:`mcumgr` (optional)
220
221Direct image upload and Image mapping to MCUboot slot
222=====================================================
223
224Currently the mcumgr supports, for direct upload, 4 target images, of which first two are mapped
225into MCUboot primary (slot-0) and secondary (slot-1) respectively.
226
227For clarity, here is DTS label to slot to ``<image>`` translation table:
228
229 +-----------+--------+------------+
230 | DTS label | Slot | -n <image> |
231 +===========+========+============+
232 | "image-0" | slot-0 | 1 |
233 +-----------+--------+------------+
234 | "image-1" | slot-1 | 0, 1 |
235 +-----------+--------+------------+
236 | "image-2" | | 2 |
237 +-----------+--------+------------+
238 | "image-3" | | 3 |
239 +-----------+--------+------------+
240
241Upload the signed image
242=======================
243
244To upload the signed image, refer to the documentation for your chosen tool, select the new
245firmware file to upload and begin the upload.
246
247.. note::
248
249 At the beginning of the upload process, the target might start erasing
250 the image slot, taking several dozen seconds for some targets.
251
252List the images
253===============
254
255A list of images (slot-0 and slot-1) that are present can now be obtained on the remote target device using
256the tool of your choice, which should print the status and hash values of each of the images
257present.
258
259Test the image
260==============
261
262In order to instruct MCUboot to swap the images, the image needs to be tested first, making sure it
263boots, see the instructions in the tool of your choice. Upon reboot, MCUBoot will swap to the new
264image.
265
266.. note::
267 There is not yet any way of getting the image hash without actually uploading the
268 image and getting the hash.
269
270Reset remotely
271==============
272
273The device can be reset remotely to observe (use the console output) how MCUboot swaps the images,
274check the documentation in the tool of your choice. Upon reset MCUboot will swap slot-0 and
275slot-1.
276
277Confirm new image
278=================
279
280The new image is now loaded into slot-0, but it will be swapped back into slot-1 on the next
281reset unless the image is confirmed. Confirm the image using the tool of your choice.
282
283Note that if you try to send the very same image that is already flashed in
284slot-0 then the procedure will not complete successfully since the hash values
285for both slots will be identical.
286
287Download file from File System
288******************************
289
290SMP server supports downloading files from File System on device via
291:file:`mcumgr`. This is useful with FS log backend, when files are stored in
292non-volatile memory. Build and flash both MCUboot and smp_svr applications and
293then use the tool of your choice to download files from the file system.
294