Hi, I created a PR with implementation of monitor protocol/interface for nimble. This is the same protocol as used by BlueZ and Zephyr for logging which means we already have nice tools available for analysis.
PR: https://github.com/apache/incubator-mynewt-core/pull/362 Protocol: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/btsnoop.txt Basically, with this code you can get complete HCI traces, (partial) nimble logging and console output over single UART or RTT in real time.Unfortunately, at the moment it can be used easily on Linux where you can capture and decode logs using btmon tool. It is then possible to open saved logs in Wireshark on other platforms. Some information on how to use it, let's start with configuration over UART: CONSOLE_UART: 0 BLE_MONITOR_UART: 1 You will also most probably need to enable some other console, since UART console is disabled. There are two options here: - CONSOLE_RTT - bidirectional console over RTT - CONSOLE_BLE_MONITOR - output-only console over monitor Now the monitor interface is accessible over UART with default baudrate of 1M, use btmon to access it: $ btmon -d /dev/ttyUSB0 --tty-speed 1000000 -p 8 Bluetooth monitor ver 5.45 --- /dev/ttyUSB0 opened --- The major problem with UART is that it usually "produces" some unwanted data e.g. during reset and this makes btmon stop recording. I guess the most reliable way to use it is to break on main(), start btmon and then continue. But fortunately, it works much better over RTT: BLE_MONITOR_RTT: 1 You can use any console with RTT, including RTT console since monitor uses dedicated upstream buffer. The only problem here is that btmon can only read data from TTY so I created small tool to redirect data from RTT to PTY: https://github.com/codecoup/tools-rtt2pty/. There is no readme yet, but with nRF5x and J-Link installed in default location it should be enough to just launch it: $ rtt2pty & Connected to: J-Link OB-SAM3U128-V2-NordicSemi compiled Mar 2 2017 12:22:13 S/N: 683111475 Searching for RTT control block... Found 3 up-buffers. Using buffer #1 (size=256) PTY name is /dev/pts/3 As you can see I run it in the background - as long as you do not either restart hw or load application which places RTT control block at different place in RAM, you do not need to restart neither rtt2pty or connected btmon. Now btmon: $ btmon -d /dev/pts/3 Bluetooth monitor ver 5.45 --- /dev/pts/3 opened --- And that's it for basic setup. Few more options (and default values) which may come in handy: BLE_MONITOR_UART_BAUDRATE: 1000000 -> UART baudrate (1M) BLE_MONITOR_RTT_BUFFERED: 1 -> double buffering for RTT, see below BLE_MONITOR_DEBUG: 0 -> redirect applicable nimble logs to monitor instead of console, see below for additional info about nimble logging The double buffering for RTT bears some explanation. For maximum performance, monitor packets are written directly to RTT buffer in chunks. This assumes that there is something on the other side to read the data (like rtt2pty running in the background), as otherwise nimble will block when RTT runs out of space waiting for someone to read the data - we cannot just discard some chunk of data as it will break the protocol. To avoid this an intermediate buffer is created (enabled by default) where complete monitor packet is composed and then written at once or discarded. In worst case, there will be just some dropped packets but nimble won't block. This however requires extra space for this buffer and also extra copy to write form intermediate buffer to RTT. Another part of this PR are improvements in nimble logging. This is kind of side-effect of using monitor interface, but I think an useful one. Since logs in nimble are "composed" using multiple macro invocations the were not really suitable to work with monitor which expects single line log at once. I created set of new macros and helpers to have logs printf-ed in single line along with function name by default. The old macros are still in place since I updated only logs messages in crypto toolbox and GAP - se respective commits for more explanation there. Things still to do here: - make buffers size configurable (for UART, RTT and logging) - they consume some RAM now, it can be decreased at least in default configuration - add statistics for dropped packets when using RTT double buffering - update remaining logs to printf style Oh, and in case you wonder how btmon trace with nimble stuff looks like, here's an example from bleprph: https://gist.github.com/andrzej-kaczmarek/118de10190192fbe76c4c2a2a7bf9299. Comments? Best regards, Andrzej
