It is possible to modify some predefined settings for the STM32CubeMonitor application.
The various settings are defined in a settings.js file located under the <homedir>/.STMicroelectronics/stm32cubemonitor directory for Windows and Linux, and under <homedir>/Library/stm32cubemonitor for macOS.
When changing a setting, the modification is only applied at the next STM32CubeMonitor startup.
The "settings.js" file contains a javascript object provided to the node-red engine at startup. It mainly contains of several configuration settings for the node-red framework, but we also define a few specific settings for the STM32CubeMonitor application. These STM32CubeMonitor-specific settings are described below. The grey area is the section extract from the "settings.js" file that must be modified to update the settings.
1. stlinkReconnectTime
The stlinkReconnectTime parameter is the retry time in milliseconds to detect that an ST-LINK has been connected or disconnect to the host PC. The default value is 15000 ms. The application polls the ST-LINK driver every stlinkReconnectTime ms to discover potential newly connected or disconnected ST-LINKs. This information is used to update the acq in/out node statuses.
Extract from settings.js file
// Retry time in milliseconds for stlink
stlinkReconnectTime: 15000,
2. connectionType
The connectionType parameter allows selection of the type of connection established between the ST-LINK driver and the ST-LINK. It can take two different values:
- "p2p": (default) "peer to peer" is used to establish a direct connection between the ST-LINK driver and the ST-LINK. This is the most efficient connectionType in terms of performance, but in this mode the connection is exclusive - meaning that no other application can connect to the ST-LINK in parallel.
- "tcp": the connection between the ST-LINK driver and the ST-LINK is not direct, and passes through a TCP server. As the TCP server manages all communication with the ST-LINK, the ST-LINK remains accessible to other applications using the TCP server.The main drawback of this connectionType is the performance penalty, hence it should be reserved for cases where several applications need to access to the ST-LINK in parallel. This mode assumes stLinkServer driver has been installed on the host. For more information on how to install stLinkServer, please refer to STLinkServer installation procedure.
For more information on the associated use case, please refer to STM32CubeMonitor: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 STM32CubeMonitor: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 file location can be configured by changing the directory path provided in the logpath entry in the settings.js file. By default, the directory path is set to the path defined by the $LOGPATH environment variable or (if the $LOGPATH environment variable is undefined) is set to the <homedir>/log directory.
There are two ways to update the directory path:
- by updating the $LOGPATH environment variable on the host system,
or
- by setting a new path in the "settings.js" logpath entry. For instance, the
logpath: /my-personal-path/my-directory/my-sub-directory,. Please keep in mind that the path is OS specific and should use OS-specific separators. To get rid of OS-specific separators, thepath.join(...)function from node.js can be used, as is done in default settings.js.
Extract from settings.js file
// the directory path in which to save the data log files
// by default the path is set to the 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 troubleshoot the STM32CubeMonitor application, a debug logger mechanism is available. The level of record logging can be modified by changing the level entry (see the object structure in "settings.js" below). There are 2 logging mechanisms, one defined by the node-red framework, and one specific to STM32CubeMonitor. Hence the level entry is shared by both logging mechanisms, meaning that changing the entry affects the level for the node-red generic logger and the STM32CubeMonitor-specific one. The logger level options are:
- fatal - only those errors which make the application unusable are 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
Warning : trace and debug level must be used only to debug the tool. This trace levels generate huge data and can slow down the application or halt the tool after some time.
The resulting files where STM32CubeMonitor logging are recorded are under the $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
}
}
5. project mode
In order to activate the project mode, the projects setting "enabled" must be set to true.
Warning : git must be installed on the computer.
Extract from settings.js file
projects: {
/** To enable the Projects feature, set this value to true */
enabled: true,
workflow: {
/** Set the default projects workflow mode.
* - manual - you must manually commit changes
* - auto - changes are automatically committed
* This can be overridden per-user from the 'Git config'
* section of 'User Settings' within the editor
*/
mode: "manual",
},
},
6. jlink probe
It is possible to disable the Segger jlink probe in settings.js. When disabled, the jlink nodes will not be present in the palette and will not be loaded in the flows.
Extract from settings.js file
// Segger Jlink probe support
// set to false to hide the nodes
// jlink: false,
- If the line is commented, the node will be available.
- If "jlink: true" is set, the node will be available.
- If "jlink: false" is set, the node will be hidden.