doc: Bluetooth: Document the debug monitor and btmon in general

Move the original documentation in the arduino_101 board to a common
section in the Bluetooth documentation and document the use of `btmon`
in general.

Signed-off-by: Carles Cufi <[email protected]>

Author: carlescufi

boards/x86/arduino_101/doc/index.rst

@@ -432,30 +432,8 @@ Connect to the debug server at the ARC core from a second console:
 Bluetooth Firmware
 ------------------
 
-You will only see normal log messages on the console, by default, without any
-way of accessing the HCI traffic between Zephyr and the nRF51 controller.
-However, there is a special Bluetooth logging mode that converts the console to
-use a binary protocol that interleaves both normal log messages as well as the
-HCI traffic. Set the following Kconfig options to enable this protocol before
-building your application:
-
-.. code-block:: console
-
-   CONFIG_BT_DEBUG_MONITOR=y
-   CONFIG_UART_CONSOLE=n
-
-The first item replaces the BT_DEBUG_LOG option, the second one
-disables the default printk/printf hooks, and the third one matches the console
-baudrate with what's used to communicate with the nRF51, in order not to create
-a bottleneck.
-
-To decode the binary protocol that will now be sent to the console UART you need
-to use the btmon tool from BlueZ 5.40 or later:
-
-
-.. code-block:: console
-
-   $ btmon --tty <console TTY> --tty-speed 1000000
+See :ref:`bluetooth-hci-tracing` to find out how to debug the Bluetooth
+firmware.
 
 Release Notes
 *************

doc/guides/bluetooth/bluetooth-dev.rst

@@ -42,6 +42,34 @@ To start developing using this setup follow the :ref:`Getting Started Guide
 boards that support Bluetooth and then :ref:`run the application
 <application_run_board>`).
 
+.. _bluetooth-hci-tracing:
+
+Embedded HCI tracing
+--------------------
+
+When running both Host and Controller in actual Integrated Circuits, you will
+only see normal log messages on the console by default, without any way of
+accessing the HCI traffic between the Host and the Controller.  However, there
+is a special Bluetooth logging mode that converts the console to use a binary
+protocol that interleaves both normal log messages as well as the HCI traffic.
+Set the following Kconfig options to enable this protocol before building your
+application:
+
+.. code-block:: console
+
+   CONFIG_BT_DEBUG_MONITOR=y
+   CONFIG_UART_CONSOLE=n
+
+Setting :option:`CONFIG_BT_DEBUG_MONITOR` to ``y`` replaces the
+:option:`CONFIG_BT_DEBUG_LOG` option, and setting :option:`CONFIG_UART_CONSOLE`
+to ``n`` disables the default ``printk``/``printf`` hooks.
+
+To decode the binary protocol that will now be sent to the console UART you need
+to use the btmon tool from :ref:`BlueZ <bluetooth_bluez>`:
+
+.. code-block:: console
+
+   $ btmon --tty <console TTY> --tty-speed 115200
 
 QEMU with an external Controller
 ================================

doc/guides/bluetooth/bluetooth-tools.rst

@@ -162,6 +162,18 @@ transports when building a single-mode, Zephyr-based BLE Controller:
 * USB: Use the :ref:`hci_usb <bluetooth-hci-usb-sample>` sample and then
   treat it as a Host System Bluetooth Controller (see previous section)
 
+HCI Tracing
+===========
+
+When running the Host on a computer connected to an external Controller, it
+is very useful to be able to see the full log of exchanges between the two,
+in the format of a :ref:`bluetooth-hci` log.
+In order to see those logs, you can use the built-in ``btmon`` tool from BlueZ:
+
+.. code-block:: console
+
+   $ btmon
+
 .. _bluetooth_ctlr_bluez:
 
 Using Zephyr-based Controllers with BlueZ