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
The sizes and configurations of slot0 and slot1 are asymmetrical.
133
135
134
-
The boards in |BMshort| have a reserved size of 31 kB for MCUboot and 64 kB for FW loader (including MCUboot meta data).
135
-
The sizes are set large enough to include logging and other debugging information required for development.
136
-
If you want to keep optimization and log level equal to the default in the sample but want to maximize the size available for application and storage, you can adjust the partition as recommended in Development column.
137
-
The Release column shows the recommended size to be used, given that the project is optimized as described.
138
-
You cannot update the ``boot_partition`` after release.
139
-
Set the size to match the size given by the project.
140
-
Set the size for the ``slot1_partition`` to accommodate for updates.
141
-
There is a recommended size for both partitions, but you need to consider how much space is needed for each partition in your project.
136
+
* **DK board** - Represents the partition size that you can find in the board definition files (.dts) that have been defined for the MCUboot board target in |BMshort|.
137
+
These sizes are not optimized but set large enough to provide enough memory to do development on multiple domains without having to adjust the partition size.
142
138
143
-
If you are not using a DK board target, refer to :ref:`ug_dfu_preparing_dfu_board` for how to partition the memory using the devicetree.
139
+
* **Development** - Represents the partition size that can be used to maximize the application space when running with default configuration of the MCUboot and firmware loader project.
140
+
This setting does not include extra space in the ``slot1_partition`` to accommodate for updates without the risk of having to adjust the partition size.
141
+
142
+
* **Release** - Represents the partition size recommended when the MCUboot and firmware loader projects are optimized for release.
143
+
See :ref:`dfu_memory_partitioning_optimize` for details.
144
+
The ``boot_partition`` (MCUboot) cannot be updated after the release and the size must be set to match the project.
145
+
The partition size set for ``slot1_partiton`` (firmware loader) must contain extra space to accommodate for later updates.
146
+
147
+
.. _dfu_memory_partitioning_optimize:
144
148
145
-
Reference sizes of the MCUboot and the Firmware loader can be achieved using the default configuration of :ref:`ble_mcuboot_recovery_entry_sample`
149
+
Optimizing your project for release
150
+
***********************************
146
151
147
-
For minimal size, amend the Firmware loader configuration using the following Kconfig options:
152
+
Reference sizes of the MCUboot and the firmware loader can be achieved using the default configuration of :ref:`ble_mcuboot_recovery_entry_sample`.
153
+
154
+
For minimal size, amend the firmware loader configuration using the following Kconfig options:
Copy file name to clipboardExpand all lines: doc/nrf-bm/drivers.rst
+5-32Lines changed: 5 additions & 32 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,45 +11,18 @@ This will mostly be more higher-level drivers and should be seen as a supplement
11
11
Only the drivers located under :file:`nrf-bm/drivers` and the ones provided in nrfx are in the scope of the |BMshort|.
12
12
All other drivers that are included in the distribution must be ignored when working with the Bare Metal option.
13
13
14
-
Pre-allocated resources
15
-
***********************
16
-
17
-
Some peripherals will be pre-allocated by the system and must not be accessed directly by the application.
14
+
Some peripherals are pre-allocated by the system and must not be accessed directly by the application.
18
15
19
16
By default, |BMshort| initializes a system timer that is used by both the :ref:`lib_bm_timer` and logging timestamp.
20
-
This will allocate ``GRTC`` channel ``0`` and ``GRTC_2_IRQn``.
17
+
This allocates the ``GRTC`` channel ``0`` and ``GRTC_2_IRQn``.
21
18
The initialization starts ``GRTC`` and enables ``SYSCOUNTER``, as required by the SoftDevice.
22
19
23
-
When SoftDevice is enabled, it takes the ownership of the peripherals that it needs.
20
+
When the SoftDevice is enabled, it takes the ownership of the peripherals that it needs.
24
21
They will not be available for application to use.
25
-
The SoftDevice is reusing both the `SoftDevice Controller`_ and the `Multiprotocol Service Layer`_ from the nRF Connect SDK.
22
+
The SoftDevice is reusing both the `SoftDevice Controller`_ and the `Multiprotocol Service Layer`_ from the |NCS|.
26
23
See the Integration Notes documentation for these libraries to get an overview of the resource it will be using.
27
24
28
-
For details on SoftDevice behavior, see the `S115 SoftDevice Specification`_.
29
-
30
-
nrfx
31
-
****
32
-
33
-
The |BMshort| is set up to use nrfx that comes with the nRF Connect SDK.
34
-
35
-
In |BMshort|, it is expected that the application uses either the nrfx driver or, if needed, interacts directly with the peripheral register interface (nrf hal).
36
-
37
-
To learn more, see the `nrfx documentation`_ that is distributed as separate bundle.
38
-
The nrfx source code is located in :file:`../modules/hal/nordic/nrfx`.
39
-
40
-
.. note::
41
-
42
-
The CMake in Bare Metal option is already set up to include the source code from nrfx.
43
-
44
-
To include and start using the nrfx driver:
45
-
46
-
* Include the interface file, like :file:`#include <nrfx_spim.h>` for the SPI Master driver.
47
-
* Start adding code in your application to set up, initialize and start using the driver.
48
-
49
-
To start interacting directly with a peripheral through the register interface:
50
-
51
-
* Include the interface file, like :file:`#include <hal/nrf_gpio.h>` for GPIO.
52
-
* Start adding code interacting with the register interface (:file:`nrf_gpio_pin_write(….)` ).
25
+
For details on the SoftDevice behavior, see the `S115 SoftDevice Specification`_.
The |BMshort| is set up to use nrfx that comes with the |NCS|.
7
+
8
+
In |BMshort|, it is expected that the application uses either the nrfx driver or, if needed, interacts directly with the peripheral register interface (nrf hal).
9
+
10
+
To learn more, see the `nrfx documentation`_ that is distributed as a separate bundle.
11
+
The nrfx source code is located in :file:`../modules/hal/nordic/nrfx`.
12
+
13
+
.. note::
14
+
15
+
The CMake in |BMshort| is already set up to include the source code from nrfx.
16
+
17
+
To include and start using the nrfx driver:
18
+
19
+
* Include the interface file, like :file:`#include <nrfx_spim.h>` for the SPI Master driver.
20
+
* Start adding code in your application to set up, initialize, and start using the driver.
21
+
22
+
To start interacting directly with a peripheral through the register interface:
23
+
24
+
* Include the interface file, like :file:`#include <hal/nrf_gpio.h>` for GPIO.
25
+
* Start adding code interacting with the register interface (``nrf_gpio_pin_write``).
Copy file name to clipboardExpand all lines: doc/nrf-bm/install_nrf_bm.rst
+9-4Lines changed: 9 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -64,7 +64,7 @@ Every |BMlong| release consists of:
64
64
65
65
#. In the next page you will be prompted to **Select SDK type**, click :guilabel:`nRF Connect SDK Bare Metal`.
66
66
67
-
#. In the next page you will be prompted to **Select an SDK version (or enter the branch, tag or commit SHA) to install...**, click :guilabel:`v0.9.0` marked on the right by the label :guilabel:`Pre-packaged SDKs &Toolchains`.
67
+
#. In the next page you will be prompted to **Select an SDK version (or enter the branch, tag or commit SHA) to install...**, click :guilabel:`v1.0.0` marked on the right by the label :guilabel:`Pre-packaged SDKs &Toolchains`.
68
68
69
69
#. In the next page you will be prompted to select a destination for the SDK. The default suggestion is recommended. Then press **Enter**.
70
70
This will proceed by installing |BMshort| and the respective Toolchain it requires.
@@ -110,7 +110,7 @@ Every |BMlong| release consists of:
110
110
111
111
#. In the next page you will be prompted to **Select SDK type**, click :guilabel:`nRF Connect SDK Bare Metal`.
112
112
113
-
#. In the next page you will be prompted to **Select an SDK version (or enter the branch, tag or commit SHA) to install...**, click :guilabel:`v0.9.0` marked on the right by the label :guilabel:`GitHub`.
113
+
#. In the next page you will be prompted to **Select an SDK version (or enter the branch, tag or commit SHA) to install...**, click :guilabel:`v1.0.0` marked on the right by the label :guilabel:`GitHub`.
114
114
115
115
#. In the next page you will be prompted to select a destination for the SDK. The default suggestion is recommended. Then press **Enter**.
116
116
This will proceed by installing |BMshort|.
@@ -141,9 +141,14 @@ The samples can be found in the :file:`nrf-bm/samples` folder, and are divided i
141
141
142
142
* :file:`bluetooth` for the samples showcasing Bluetooth® LE functionalities using the SoftDevice.
143
143
See :ref:`ble_samples`.
144
-
* :file:`peripherals` for the samples showcasing various peripheral functionalities that do not require the SoftDevice.
145
-
See :ref:`peripheral_samples`.
146
144
* :file:`boot` for the samples showcasing the functionalities related to Device Firmware Update.
147
145
See :ref:`dfu_samples`.
146
+
* :file:`nfc` for the samples showcasing the functionalities of Near Field Communication (NFC).
147
+
See :ref:`nfc_samples`.
148
+
* :file:`peripherals` for the samples showcasing various peripheral functionalities that do not require the SoftDevice.
149
+
See :ref:`peripheral_samples`.
150
+
* :file:`subsys` for the samples showcasing the usage of subsystems.
151
+
See :ref:`subsys_samples`.
152
+
148
153
149
154
Each sample documentation contains full information on how to build, flash, and test the respective sample.
Copy file name to clipboardExpand all lines: doc/nrf-bm/libraries/bluetooth/ble_qwr.rst
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -47,9 +47,9 @@ Usage
47
47
The library uses a callback function to handle write authorization.
48
48
When it receives an Execute Write request, it calls the callback function with a :c:enum:`BLE_QWR_EVT_AUTH_REQUEST` event to determine whether the request should be accepted:
49
49
50
-
* To authorize the request, the callback function must return :c:macro:`BLE_GATT_STATUS_SUCCESS`.
50
+
* To authorize the request, the callback function must return ``BLE_GATT_STATUS_SUCCESS``.
51
51
The module then writes all received data and notifies the GATT server that the data is ready to use by calling the callback function again, this time with a :c:enum:`BLE_QWR_EVT_EXECUTE_WRITE` event.
52
-
* To reject the request (for example, because the received data is not valid or the application is busy), the callback function must return a BLE GATT status code other than :c:macro:`BLE_GATT_STATUS_SUCCESS`.
52
+
* To reject the request (for example, because the received data is not valid or the application is busy), the callback function must return a BLE GATT status code other than ``BLE_GATT_STATUS_SUCCESS``.
.. _`Migration notes - nRF5 SDK to nRF Connect SDK Bare Metal option`: https://docs.nordicsemi.com/bundle/nrf-bm-latest/page/migration/nrf5_bm_migration.html
100
108
.. _`S115 9.0.0-3.prototype API reference`: https://docs.nordicsemi.com/bundle/s115_9.0.0-3.prototype_api/page/topics.html
0 commit comments