|
Coming soon |
1. Introduction
The STM32CubeWBA firmware provides Real Time debug capabilities. The RTDebug module is GPIO based for a minimal impact on real time timings. The module is present, by default, into the application framework.
While enabling the RTDebug module in the application, the user can choose, among a various list of signals, the ones it wants to monitor and which GPIO is assigned for output.
Some default configurations are already presents and can ease debugging regarding System, BLE, MAC or Coexistence behaviors.
2. Concepts
2.1. RTDebug general overview
The main objectives of the RTDebug system module is to provide a GPIO probing solution:
- With accurate timings.
- That is not disturbing real time nor modifying critical executions.
- Easy to configure (debug signal selection and GPIO assignation).
- With low footprint, both memory and execution time.
Regarding these objectives, the RTDebug module is configured at compile time. Only the necessary code is compiled, according to the user configuration.
The debug signals are present, by default, in the system framework (modules and interfaces) and the Link Layer libraries (BLE, 802.15.4 and concurrent modes). If those signals are always present, the effective use is conditioned to the user configuration.
- If the signal is selected, it will trigger the associated GPIO.
- If the signal is not selected at compile time, it will not trigger any GPIO.
2.2. RTDebug configuration
RTDebug module configuration is done at compilation time. This aims to determined which signal is activated and to which GPIOs it is attributed. This relies on definitions, enumerations and hash tables.
Three steps are required to understand / to perform the RTDebug configuration:
- Signal definition
- Debug tables
- Association between Signal and GPIO
2.2.1. Signal definition
The signal definition takes place in the debug_signals.h header file. The signals are defined in their respective enumeration types, for instance, the system signal enumeration is named system_debug_signal_t and contains all the system relative signals. This enumeration is important since it is used later for signal activation or deactivation as a parameter. There are also dedicated enumeration for link layer or application.
The enumeration rt_debug_signal_t is the global signal definition. In this enumeration. you can find all the signals available on your target - It englobe all the possible signals.
Each signal has a specific function and is design to address a specific use case. Some are dedicated to link layer activities some others are dedicated to system events and some can be used to describe application steps.
2.2.2. Debug tables
The debug tables are like hash-tables. They are used to associate a specific signal to a given index inside the rt_debug_signal_t enumeration. They are located in the local_debug_tables.h header file.
2.2.3. Signal/GPIO association
The debug_config.h is the most useful file for RTDebug configuration since it handles the association configuration between a signal and its dedicated GPIO but also manage the activation or not of a signal.
Therefore, if you want to configure a signal activation and/or its GPIO output, you shall focus on this file configuration.
2.3. RTDebug Signals
The list of signals handled by the module can not fully stand here. However, you must know that there are 3 main types of signals:
- System signals:
- Signals dedicated to system tracking
- I.e.: Low power activation, low power deactivation, system clock configuration, etc.
- Link layer signals:
- Signals dedicated to link layer activities tracking
- I.e.: HCI write done, Physical calibration, scheduler event registration, etc.
- Application signals:
- Signals that can be implemented and managed by the user.
- I.e: Application initialization, etc.
2.4. RTDebug used pins
The RTDebug is designed to be compliant with any version of the WBA product. Therefore, its pin configuration is restricted and is following:
| GPIO Group | Number | ||||
|---|---|---|---|---|---|
| GPIO A | 5 | 12 | 15 | ||
| GPIO B | 3 | 4 | 8 | 12 | 15 |
2.5. RTDebug default configurations
To ease user debug experience, dedicated teams have already worked on default configuration for specific use cases (BLE, MAC, Coex, system, etc.).
Addressed configurations can deal with most common behaviors issues and give a quick overview of the situation.
The default configuration are present at the start of the debug_config.h file and just require the user to activate them.
3. Interfaces
The RTDebug is quite minimalist since for the main part it is already implemented inside the application, the system calls, the link layer routines, etc.
However, user could want to integrate some probing on his own work and could necessitate to access signal activation and deactivation functions.
The available function are the following:
| RT_DEBUG_GPIO_Init |
|---|
|
Description
|
| APP_DEBUG_SIGNAL_SET |
|---|
|
| APP_DEBUG_SIGNAL_RESET |
|---|
|
| APP_DEBUG_SIGNAL_TOGGLE |
|---|
|
4. How to
TBD.