You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+33-33Lines changed: 33 additions & 33 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
# Pelion Client Mbed OS Example
2
2
3
3
This is a simplified example with the following features:
4
-
- Mbed OS 5.13 and Pelion Device Management Client 3.3.0
4
+
- Mbed OS 5.13.0 and Pelion Device Management Client 3.3.0
5
5
- Support for FW Update
6
6
- 200 lines of code + credential sources
7
7
@@ -28,16 +28,16 @@ This section is intended for developers to get started, import the example appli
28
28
## Requirements
29
29
30
30
- Mbed CLI >= 1.10.0
31
-
31
+
32
32
For instructions on installing and using Mbed CLI, please see our [documentation](https://os.mbed.com/docs/mbed-os/latest/tools/developing-mbed-cli.html).
You should generate your own API key. Pelion Device Management is available for any Mbed developer. Create a [free trial](https://os.mbed.com/pelion-free-tier).
39
39
40
-
For instructions on how to generate your API key, please see our [documentation](https://cloud.mbed.com/docs/current/integrate-web-app/api-keys.html#generating-an-api-key).
40
+
For instructions on how to generate your API key, please see our [documentation](https://cloud.mbed.com/docs/current/integrate-web-app/api-keys.html#generating-an-api-key).
41
41
42
42
## Deploying
43
43
@@ -61,7 +61,7 @@ This repository is in the process of being updated and depends on few enhancemen
61
61
- Press 'i' to print endpoint name
62
62
- Press Ctrl-C to to unregister
63
63
- Press 'r' to reset storage and reboot (warning: it generates a new device ID!)
64
-
64
+
65
65
## Further information and requirements
66
66
67
67
Check the public tutorial for further information:
@@ -73,13 +73,13 @@ Check the public tutorial for further information:
73
73
- Device initializes but can't register to Pelion
74
74
75
75
Error: `client_error(3) -> Bootstrap server URL is not correctly formed`
76
-
76
+
77
77
Solution: Format the the storage by pressing 'r' in the serial terminal.
78
-
78
+
79
79
# Porting process to add support for an Mbed Enabled board
80
80
81
81
There are many steps involved in this process. We generally recomend the following steps:
82
-
82
+
83
83
1. Configure the application using `mbed_app.json`
84
84
- Configure the default connectivity
85
85
- Configure the KVSTORE area to store credentials (internal or external memory)
@@ -104,19 +104,19 @@ You can extend or override the default configuration using `mbed_app.json` in th
104
104
### a. Connectivity
105
105
106
106
Specify the default IP connectivity type for your target. It's essential with targets that lack default connectivity set in `targets.json` or for targets that support multiple connectivity options. For example:
The possible options are `ETHERNET`, `WIFI` and `CELLULAR`.
111
-
111
+
112
112
Depending on connectivity type, you might have to specify more configuration options. Review the [documentation](https://os.mbed.com/docs/mbed-os/latest/porting/porting-connectivity.html) for further information.
113
113
114
114
### b. Storage for credentials
115
115
116
116
Start by getting familiar with the multiple [storage options](https://os.mbed.com/docs/mbed-os/latest/reference/storage.html) and configurations supported in Mbed OS.
117
117
118
118
Then start designing the system memory map, the location of components (whether they are on internal or external memory), and the corresponding base addresses and sizes. You may want to create a diagram similar to the one below to help you to make design decisions:
119
-
119
+
120
120
+--------------------------+
121
121
| |
122
122
| |
@@ -151,19 +151,19 @@ You can extend or override the default configuration using `mbed_app.json` in th
151
151
In cases where the MCU has two separate memory banks, it's appropiate to allocate the bootloader and base application in one bank, and KVSTORE storage at the begining of the second bank followed by a firmware candidate storage.
152
152
153
153
-**Option 1:** Allocating credentials in internal memory
154
-
154
+
155
155
**This is the preferred option whenever possible**. Make sure `TDB_INTERNAL` is the type of storage selected in `mbed_app.json`. Specify the base address depending on the available memory in the system. The size of this section should be aligned with the flash erase sector. The value should be multiple of 4 with a minimum of 24KB and upwards depending on the use case (for example the usage of certificate chain will increase the need of storage to hold those certificates). An example of this configuration can be seen for the `NUCLEO_F429ZI` platform in this application.
-**Option 2:** Allocating credentials in external memory:
162
-
162
+
163
163
This is possible when the platform has an storage device wired to the MCU (could be on-board or external component). Make sure `FILESYSTEM` is specified as type of storage. The blockdevice and filesystem should be one of the supported in Mbed OS (see [docs](https://os.mbed.com/docs/mbed-os/latest/porting/blockdevice-port.html)).
164
-
164
+
165
165
An example of this configuration can be seen for the `K64F` platform in the [mbed-cloud-client-example](https://github.com/ARMmbed/mbed-cloud-client-example/blob/master/mbed_app.json#L32)
166
-
166
+
167
167
"storage.storage_type" : "FILESYSTEM",
168
168
"storage_filesystem.blockdevice" : "SD",
169
169
"storage_filesystem.filesystem" : "LITTLE",
@@ -175,15 +175,15 @@ You can extend or override the default configuration using `mbed_app.json` in th
175
175
### c. Storage for firmware updates
176
176
177
177
Before enabling FW updates, it's recomended that the application is able to initialize the network and connect to Pelion DM.
178
-
179
-
Once the connection is successfull, you can follow the steps below to enable the platform to receive FW updates. Note the configuration for the application in this section should match with the one on the bootloader - see section below.
180
-
178
+
179
+
Once the connection is successfull, you can follow the steps below to enable the platform to receive FW updates. Note the configuration for the application in this section should match with the one on the bootloader - see section below.
180
+
181
181
- Common configuration
182
-
182
+
183
183
Regardless of where the firmware candidate is located (internal or external), there is a need to have a bootloader in place. The binary of the booloader can be specified with the `bootloader_img` option. The address and size of the bootloader determines the `application-details` and `bootloader-details` options. The value of `bootloader-details` can be obtained by running the binary on the target and observing the serial output.
184
-
184
+
185
185
Review the [mbed-bootloader](https://github.com/ARMmbed/mbed-bootloader#configurations) guidelines on how these options should be selected. Review the [bootloader configuration](2.-Bootloader-configuration) section below for more information.
186
-
186
+
187
187
Copy the compiled bootloader from `mbed-bootloader/BUILDS/<TARGET>/<TOOLCHAIN>-TINY/mbed-bootloader.bin` to `bootloader/mbed-bootloader-<TARGET>.bin`.
188
188
189
189
Edit `mbed-os-pelion-example/mbed_app.json` and modify the target configuration to match with the one in `bootloader_app.json`.
@@ -195,34 +195,34 @@ You can extend or override the default configuration using `mbed_app.json` in th
195
195
-`target.app_offset` is relative offset to `flash-start-address` you specified in `mbed_app.json` and `bootloader_app.json`, and is the hex value of the offset specified by `application-start-address` in `bootloader_app.json`. For example, `(MBED_CONF_APP_FLASH_START_ADDRESS+65*1024)` dec equals `0x10400` hex.
196
196
197
197
-`target.header_offset` is also relative offset to the `flash-start-address` you specified in the `bootloader_app.json`, and is the hex value of the offset specified by `update-client.application-details`. For example, `(MBED_CONF_APP_FLASH_START_ADDRESS+64*1024)` dec equals `0x10000` hex.</span>
198
-
198
+
199
199
An example of this configuration can be seen for the `NUCLEO_F429ZI` platform.
-**Option 1:** Allocating the firmware update candidate in internal memory
208
208
209
209
**This is the preferred option whenever possible**. Make sure `ARM_UCP_FLASHIAP` is selected in `update-storage` in `mbed_app.json`. This area should be located at the end of the flash after the KVSTORE area. Specify the `storage-address`, `storage-size` and `storage-page` as required. The `application-details` option should point at the end of the bootloader area. An example of this configuration can be seen for the `NUCLEO_F429ZI` platform.
-**Option 2:** Allocating the firmware update candidate in external memory
217
-
217
+
218
218
When using an external device to the MCU to store the firmware candidate, make sure `ARM_UCP_FLASHIAP_BLOCKDEVICE` is specified as type of `update-storage`. Specify the `storage-address`, `storage-size` and `storage-page` as required.
219
-
219
+
220
220
An example of this configuration can be seen for the `K64F` platform in the [mbed-cloud-client-example](https://github.com/ARMmbed/mbed-cloud-client-example/blob/master/mbed_app.json#L32)
0 commit comments