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: features/FEATURE_UVISOR/README.md
+16-11Lines changed: 16 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -129,15 +129,14 @@ In the code above we specified 3 elements:
129
129
1. Main box Access Control Lists (ACLs). Since with uVisor enabled everything runs in unprivileged mode, we need to make sure that peripherals that are accessed by the OS and the main box are allowed. These peripherals are specified using a list like the one in the snippet above. For the purpose of this example we provide you the list of all the ACLs that we know you will need. For other platforms or other applications you need to determine those ACLs following a process that is described in a [section](#the-main-box-acls) below.
130
130
1. App-specific uVisor configurations: `UVISOR_SET_MODE_ACL`. This macro sets the uVisor mode (enabled) and associates the list of ACLs we just created with the main box.
131
131
132
-
Before compiling, we need to add a custom target that inherits all the features of the original `K64F` target, and enables the uVisor feature. To do so, add the file `~/code/uvisor-example/mbed_app.json` with the following content:
132
+
Before compiling, we need to override the original `K64F` target to enable the uVisor feature. To do so, add the file `~/code/uvisor-example/mbed_app.json` with the following content:
133
133
134
134
```JSON
135
135
{
136
-
"custom_targets": {
137
-
"K64F_SECURE": {
138
-
"inherits": ["K64F"],
139
-
"extra_labels_add":["K64F", "UVISOR_SUPPORTED"],
140
-
"features_add": ["UVISOR"]
136
+
"target_overrides": {
137
+
"K64F": {
138
+
"target.features_add": ["UVISOR"],
139
+
"target.extra_labels_add": ["UVISOR_SUPPORTED"]
141
140
}
142
141
}
143
142
}
@@ -147,16 +146,16 @@ Before compiling, we need to add a custom target that inherits all the features
147
146
148
147
**Checkpoint**
149
148
150
-
Compile the application again, but this time targeting `K64F_SECURE`:
149
+
Compile the application again. This time the `K64F` target will include the new features and labels we provided in `mbed_app.json`;
Re-flash the device and press the reset button. The device LED should be blinking as in the previous case.
@@ -290,7 +289,13 @@ A few things to note in the code above:
290
289
291
290
**Checkpoint**
292
291
293
-
Compile the application again, re-flash the device, and press the reset button. The device LED should be blinking as in the previous case.
292
+
Compile the application again:
293
+
294
+
```bash
295
+
$ mbed compile -m K64F -t GCC_ARM
296
+
```
297
+
298
+
Re-flash the device, and press the reset button. The device LED should be blinking as in the previous case.
294
299
295
300
If you don't see the LED blinking, it means that the application halted somewhere, probably because uVisor captured a fault. You can setup the uVisor debug messages to see if there is any problem. Follow the [Debugging uVisor on mbed OS](DEBUGGING.md) document for a step-by-step guide.
You now need to compile your application using uVisor in debug mode. This operation requires some more advanced steps, which are described in detail in the [Debugging uVisor on mbed OS](DEBUGGING.md) document. The main idea is that you compile the application in debug mode:
and then use a GDB-compatible interface to flash the device, enable semihosting, and access the uVisor debug messages. Please read the [Debugging uVisor on mbed OS](DEBUGGING.md) document for the detailed instructions.
0 commit comments