It is possible to modify some predefined settings for the STM32CubeMonitor application.
The various settings are defined in a settings.js file located under <homedir>/.STMicroelectronics/stm32cubemonitor directory
for Windows and Linux, and under <homedir>/Library/stm32cubemonitor for macOS.
When changing a setting, the modification will only be applied at next STM32CubeMonitor startup.
The settings.js file contains a javascript object provided to node-red engine at startup. It mainly contains several configuration settings for node-red framework, but we also defined few specific ones for STM32CubeMonitor application. These STM32CubeMonitor specific settings are described below. The grey area is the section extract from the settings.js file that should be modified to update the setting.
1. stlinkReconnectTime
The stlinkReconnectTime is the retry time in milliseconds to detect a stlink has been connected or disconnect to the host PC. The default value is 15000 ms. The application is polling each stlinkReconnectTime ms the stlink driver to discover new potential connected or disconnected stlink. This information is used to update acq in / out nodes status.
Extract from settings.js file
// Retry time in milliseconds for stlink
stlinkReconnectTime: 15000,
2. connectionType
The connectionType allows to select the type of connection established between the stlinkdriver and the stlink. It can take two different values:
- "p2p": (default) the "peer to peer" is used to establish a direct connection between stlinkdriver and the stlink. This is the most efficient connectionType in term of performance but in this mode the connection is exclusive meaning that no other application can connect to the stlink in parallel.
- "tcp": the connection between stlinkdriver and the stlink is not direct and is passing through a tcp-server. As the tcp-server is managing all the communication with the stlink, the stlink remains accessible to other applications that is using the tcp-server.The main drawback ot this connectionType is the performance penalties, hence it should be reserved to the cases where several applications need to access to the stlink in parallel. This mode assumes the stLinkServer driver has been installed on the host. For more information on how to install the stLinkServer, please refer to STLinkServer installation procedure.
For more information on the associated use case, please refer to How to configure shared mode.
Extract from settings.js file
// Protocol to use by stLinkDriver to communicate with the probe:
// - "tcp" to pass through to tcp-server assuming the stLinkServer is installed on the host
// - "p2p" connect directly to the probe (default)
connectionType: "p2p",
3. logpath
As described in How to record and replay data , it is possible to configure the processing node to log the data received from the MCU target to a file . The location of this file can be configured by changing the directory path provided in logpath entry of the settings.js file. By default, the directory path is set to the path defined by $LOGPATH environment variable or (if the $LOGPATH environment variable is undefined) is set to <homedir>/log directory.
There are 2 ways to update the directory path :
- either by updating the $LOGPATH environment variable on the host system,
- or by setting a new path in settings.js logpath entry. For instance,
logpath: /my-personal-path/my-directory/my-sub-directory,. Please keep in mind the path is OS specific and should use OS specific separator. To get rid of OS specific separator, thepath.join(...)function from node.js can be used as done in default settings.js.
Extract from settings.js file
// the directory path where to save le data log files
// by default le path is set to LOGPATH environment variable if it exists, otherwise it is set to homedir/log
logpath: process.env.LOGPATH || path.join(homedir, "log"),
4. log level
In order to be able to troubleshoot the STM32CubeMonitor application, a debug logger mechanism is available. The level of logging to be recorded can be modified by changing the level entry (see below the object structure in settings.js). Actually there are 2 logging mechanisms, one defined by node-red framework and one specific to STM32CubeMonitor. Hence the level entry is shared by both logging mechanisms, meaning that changing the entry will affect the level for node-red generic logger and STM32CubeMonitor specific one. The logger level options are:
- fatal - only those errors which make the application unusable should be recorded
- error - record errors which are deemed fatal for a particular request + fatal errors
- warn - record problems which are non fatal + errors + fatal errors
- info - record information about the general running of the application + warn + error + fatal errors
- debug - record information which is more verbose than info + info + warn + error + fatal errors
- trace - record very detailed logging + debug + info + warn + error + fatal errors
- off - turn off all logging
The resulting files where STM32CubeMonitor logging are recorder are under $TMP/STM32CubeMonitor/logs directory.
Extract from settings.js file
logging: {
// Only console logging is currently supported
console: {
// Level of logging to be recorded. Options are:
// fatal - only those errors which make the application unusable should be recorded
// error - record errors which are deemed fatal for a particular request + fatal errors
// warn - record problems which are non fatal + errors + fatal errors
// info - record information about the general running of the application + warn + error + fatal errors
// debug - record information which is more verbose than info + info + warn + error + fatal errors
// trace - record very detailed logging + debug + info + warn + error + fatal errors
// off - turn off all logging (doesn't affect metrics or audit)
level: "info",
// Whether or not to include metric events in the log output
metrics: false,
// Whether or not to include audit events in the log output
audit: false
}
}