Log Interface

The Log module provides APIs to instrument source code. More...

Data Structures
struct	Log_Module
	Log module. More...

Macros
#define	Log_TI_LOG_VERSION   0.1.0
	Log version. More...
#define	Log_MODULE_DEFINE(name, init)   const Log_Module LogMod_ ## name = init
	Defines a log module. More...
#define	Log_MODULE_DEFINE_WEAK(name, init)   const __weak Log_Module LogMod_ ## name = init
	Defines Log module as weak. More...
#define	Log_MODULE_USE(name)   extern const Log_Module LogMod_ ## name
	Declares a reference to a log module. More...
#define	LOG_MODULE_SYM(name)   LogMod_ ## name
	Resolves to the symbol name of the log module. More...
#define	Log_buf(module, level, format, data, size)   _Log_buf_B(module, level, format, data, size)
	Log a continuous block of memory. More...
#define	Log_printf(module, level, ...)   _Log_printf_B(LOG_OPCODE_FORMATED_TEXT, module, level, __VA_ARGS__)
	Log an event with a printf-formatted string. More...
#define	Log_MODULE_SET_LEVELS(module, levels)
	Set a log module's log level bitmask. More...
#define	Log_MODULE_GET_LEVELS(module)
	Get a log module's log level bitmask. More...

Typedefs
typedef enum Log_Level	Log_Level
	Log level bitmask values. More...
typedef const struct Log_Module	Log_Module
typedef void(*	Log_printf_fxn) (const Log_Module *handle, uint32_t header, uint32_t headerPtr, uint32_t numArgs,...)
typedef void(*	Log_printfN_fxn) (const Log_Module *handle, uint32_t header, uint32_t headerPtr,...)
typedef void(*	Log_buf_fxn) (const Log_Module *handle, uint32_t header, uint32_t headerPtr, uint8_t *data, size_t size)

Enumerations
enum	Log_Level {   Log_DEBUG = 1 << 0,   Log_VERBOSE = 1 << 2,   Log_INFO = 1 << 4,   Log_WARNING = 1 << 6,   Log_ERROR = 1 << 8,   Log_ALL = Log_DEBUG + Log_VERBOSE + Log_INFO + Log_WARNING + Log_ERROR,   Log_NONE = 0 }
	Log level bitmask values. More...

Detailed Description

The Log module provides APIs to instrument source code.

To access the LOG APIs, the application should include its header file as follows:

#include <ti/log/Log.h>

Definitions

The following terms are used throughout the log documentation.

• Log module: A parameter passed to Log APIs to indicate which software module the log statement originated from. Modules also control the routing of logs to sinks.
• Log level: The severity or importance of a given log statement.
• Log sink: Also simply called a logger. This is a transport-specific logger implementation on the target side.
  The Logging framework is flexible such that multiple sinks may exist in a single firmware image.
• Call site: A specific invocation of a Log API in a given file or program.
• Record: The binary representation of a log when it is stored or transported by a given sink. The log record format varies slightly with each sink depending on their implementation and needs. However, they all convey the same information.
• Link Time Optimization (LTO): A feature of some toolchains that can significantly reduce the code overhead of the log statements through a process called dead code elimination. In order to maximize the benefits of this, all static libraries and application files should have LTO enabled.

Summary

The following sections describe the usage of the TI logging system implementation. This document will focus on the target (i.e. code that runs) on the embedded device. For associated PC tooling, please see the README in the tools/log/tiutils/ folder.

Design Philosophy:

• Logs target code should be as efficient as possible.
  • This means that Log APIs should minimize FLASH, RAM, and execution overhead.
• Complexity should be pushed to host side tooling where possible.
  • Even if this means that PC setup/tooling requirements are more complex.
• Multiple log sink implementations shall be able to exist in a system.
  • Where applicable, multiple instances should be supported (e.g. multiple circular buffers to collect logs)
• It shall be possible to remove logging entirely using the preprocessor
• Configuration of logging should be deferred to application compile and link time.
  • That means that the end application builder should make decisions about the logging settings. This means that TI provided libraries are not opinionated about what log levels should be enabled or how modules should be routed to sinks.
• TI's logging system will leverage SysConfig out of the box, but it should be possible to configure and use logging easily without the needing SysConfig.

Stated Limitations

• It is not possible to control which log sink is used for each call site. Routing of logs is controlled at a module level.
• A maximum of 8 arguments is supported for variadic APIs.
• Users may not add log statements to functions that are direct dependencies of delegate log functions. Not respecting this will lead to recursive emissions of the log statements added to the dependencies. The dependencies of the configured delegate function depends on which log sink is selected for a given log module. For example, if an application using the UART log sink has a Log_printf() at the application level and another in HwiP_disable(), the first call will be delegated to LogSinkUART_printf(), which then calls HwiP_disable(). This, in turn, triggers another Log_printf() that loops back to LogSinkUART_printf(), creating an endless cycle. Note that SysConfig will prevent users from adding such log statements.

Anatomy of Log Statement

At the core of the logging implementation is heavy use of the C preprocessor. When reading an application, the Log APIs may look like function calls, but the preprocessor expands them heavily.

There are several ways in which the preprocessor is used.

Global

1. To enable/disable logs globally. If ti_log_Log_ENABLE is not defined, all statements are removed by the preprocessor. This does not rely on LTO or any other optimization. It removes any traces of logs from the program.

   This define is pushed to ti_utils_build_compiler.opt whenever any Log module is enabled in SysConfig.

Module

1. To enable/disable logs by module. If ti_log_Log_ENABLE_<MyLogModuleName>=1 is not defined, all statements using that Log module are removed by the preprocessor. This does not rely on LTO or any other optimization. Removing the define removes all traces of the log from the compiled code. Just defining the symbol name ti_log_Log_ENABLE_<MyLogModuleName> without setting it to 1 will not include Log statements during compilation.

   These defines are automatically pushed to ti_utils_build_compiler.opt for all modules configured in SysConfig.

   Some TI libraries that have logging enabled also contain multiple log modules. Enabling only a subset of Log modules via the preprocessor will not cause the Log statements associated with the remaining Log modules to be removed since this is a compile-time event. The Log statements associated with individual modules can be removed from logging-enabled TI libraries by recompiling those libraries without the module-level flags in question.

2. If a Log Module's Log_Module.dynamicLevelsPtr is set to NULL, dynamic module log levels will be disabled for the module and only the constant defined 'levels' bitmap will be used for the Log Module. If a Log Module's Log_Module.dynamicLevelsPtr is not NULL, it will be set to a separate, volatile, levels bitmap for the Log Module. This separate bitmap will replace the previous, constant defined 'levels' bitmap for all module log level comparisons. In doing so, the log module's log levels will be dynamic and can be changed at runtime by the logging macro Log_MODULE_SET_LEVELS(). Changing a module's log levels as a runtime operation enables total control over which log levels are enabled.

   As mentioned, if dynamic module log levels are enabled, comparisons done by the Log APIs on a module's levels bitmap will be at runtime instead of compile-time. This will both increase code size and increase logging execution time. Before enabling dynamic module log levels, these tradeoffs should be considered.

Per Log Statement

1. (Level filtering): Insert the if statement that checks if the log level of the statement has been enabled in its module configuration. If the log level is not enabled, the process ends here.
2. (String declaration): Automate placement of constant strings, format strings, and pointers to these strings in the the nonloadable metadata section of the out file. This saves FLASH on the target. Each string contains a large amount of data, including the following:
   • File and line number of the log statement
   • The log level and module of the log statement
   • The format string
   • The number of arguments
3. (Argument counting): Log APIs are variadic in nature, up to 8 arguments are supported. However, at preprocess time, the number of arguments must be known.
4. (Name spacing): Routing from module to sink. The module parameter of the Log API controls which sink its log statements will be routed to. The preprocessor does name expansion to look up the enabled log levels and selected sink function pointers from the module's configuration structure. NOTE: The used sink may require initialization. Please verify with the specific sink documentation on how to initialize the sink.
5. (Sink API Invocation): With the names resolved and levels checked, the logger is now ready to execute the sink function. This is done via function pointer.

An simplified pseudo-C implementation of what Log_printf(LogModule_App1, Log_DEBUG, "Hello World!"); would expand to is shown below. This will not compile and is not extensive, just for illustration.

// Global log enable check, wrapped around each log site
#if defined(ti_log_Log_ENABLE)
    #if ti_log_Log_ENABLE_LogModule_App1 == 1
        // Check if the level of this specific log statement has been enabled by the module
        if (LogMod_LogModule_App1.levels & level) {
              // Note that ^^ is the record separator.
              // Pack meta information into format string. This is stored off target.
              const string logMeta =
                "LOG_OPCODE_FORMATED_TEXT^^"../../log.c"^^80^^Log_DEBUG^^LogMod_LogModule_App1^^"Hello World!"^^0";
              // Route log to the selected sink implementation.
              // This is done via function pointer.
              // The 0 indicates no arguments. If runtime arguments were
              // provided, they would follow.
              LogMod_LogModule_App1.printf(pointerToModuleConfig, 0);
        }
    #endif
#endif

From here, the logger has transferred control over to the sink implementation, which varies based on the transport (e.g. circular buffer in memory or UART).

Modules

When adding log statements to the target software, it is recommended to create a logging module for each software component in the image. Modules enable the reader to understand where the log record originated from. Some log visualizers may allow the reader to filter or sort log statements by module. It is also recommended to namespace modules.

For example, a good module name for the UART driver that exists in source/ti/drivers, could be ti_drivers_UART.

Modules also control the routing of log records to a sink. Routing is controlled via the Log Modules panel in SysConfig, but can be changed in plain C code - despite this being generally discouraged. To do it, use the macro Log_MODULE_DEFINE and pass the sink specific Log_MODULE_INIT_ to the init parameter within the Log_MODULE_DEFINE macro. Log_MODULE_INIT_ uses delegate functions for printf and buf that are implementation dependent for each sink based on the available hardware and whether the function is implemented for optimization. An example for the LogBuf sink is below, it will do the following

1. Create a module called LogModule_App1.
2. Initialize the module for use with the buffer based LogSink. Use buffer instance called CONFIG_ti_log_LogSinkBuf_0.
3. Enable only the Log_ERROR level. Other logs will not be stored.
4. Add the delegate function LogSinkBuf_printfSingleton for printf and LogSinkBuf_bufDepInjection for buf.
5. Disable dynamic log levels with NULL.

#include <ti/log/Log.h>
#include <ti/log/LogSinkBuf.h>
Log_MODULE_DEFINE(LogModule_App1,
                  Log_MODULE_INIT_SINK_BUF(CONFIG_ti_log_LogSinkBuf_0,
                                           Log_ERROR, LogSinkBuf_printfSingleton, LogSinkBuf_bufDepInjection, NULL));

TI created libraries will never use Log_MODULE_DEFINE. This leaves the choice of routing logs to their sinks to the end application writer. This is recommended when creating any static libraries to defer the final logging decisions to link time.

Each new module will instantiate a Log_Module structure with a levels bitmap and pointers to the selected sink implementation and sink configuration. See the Log_Module structure for more information.

If dynamic module log levels are enabled, each new Log_Module structure will include a pointer to a separate, volatile, levels bitmap. This new bitmap will be used for runtime comparisons of a module's log level. Two logging macros can be used to both set and get a module's log level. Log_MODULE_SET_LEVELS can be used to set the log level of a specific log module and Log_MODULE_GET_LEVELS can be used to retrieve the log level of a specific log module.

Levels

Log levels are a way to indicate the severity or importance of the contents of a particular log call site. Each call site takes an argument that allows the user to specify the level. As with modules, log visualization tools allow the user to sort or filter on a given level. This can help the reader to find important or relevant log statements in visualization.

Log levels are also used to control the emission of logs. Each call site will check that the level is enabled before calling the underlying log API.

Depending on optimization, the check at each log statement for whether the given level is enabled or not may end up being optimized away, and the entire log statement may be optimized away if the log level is not enabled.

Additionally, depending whether dynamic module log levels are enabled or not, checking the level at each log statement will be evaluated at runtime or compile-time. Enabling dynamic module log levels or disabling Link-Time-Optimisation (LTO) will cause each log statement to perform a runtime check and will also increase the code size.

if ((level) & module.levels) {
    // Call Log API
}

Optimization level -flto for both the TICLANG toolchain and GCC will typically be able to optimize the above statement.

Log Metadata

Each time a Log API is invoked, a metadata string is placed in the .out file. This string contains information about the API type, file, line module, level, and other information associated with the log call site. Each call site emits a string to a specific memory section called .log_data. In addition to this, a pointer to the string in .log_data is stored in another section called .log_ptr. Because the .log_ptr section is always in the same location, and each entry is the same size, an indexing-scheme can be used to refer to each log-string. Entry 0 in .log_ptr would point to the first string, entry 1 would point to the second string, etc. This Is necessary on some devices where transmitting an entire 32-bit address as a reference to the string is not possible, and instead an 8-bit index can be transmitted across the Log sink implementation instead. In order to use logging, this section should be added to the linker command file. By default, this section points to a nonloadable region of memory. Meaning that the metadata will not be loaded on the target device. Instead, the various logging visualization tools such as wireshark and TI ROV will read the metadata from this section and properly decode the log statements. The benefit of this approach is that very little memory is consumed on target. Additionally, the log transport only needs to store or send pointers to this meta section when a log API is called.

This approach minimizes the amount of memory consumed on device and bytes sent over the transport. This section can be loaded on target if desired or if you are creating a custom logger. The design does not preclude this.

In order to use the logging framework, the log section must be added to the linker command file. Here is a sample for the TI linker. Other examples can be found in the TI provided linker files for each toolchain.

MEMORY
{
    // List other memory regions here
    LOG_DATA (R) : origin = 0x90000000, length = 0x40000
    LOG_PTR  (R) : origin = 0x94000008, length = 0x40000
}
SECTIONS
{
     .log_data       :   > LOG_DATA, type = COPY
     .log_ptr        : { *(.log_ptr*) } > LOG_PTR align 4, type = COPY
}

Sinks

Sinks are responsible for storing or transporting the log record. In general there are two categories of sinks:

1. Those that perform storage of logs.
2. Those that stream logs over a transport medium, and thus do not perform storage.

Sinks may vary in their implementation based on the nature of the storage or transport that they support, but they all have the following in common:

• Are named ti_log_LogSink<SinkName>. Where <SinkName> is the name of the sink.
• Must implement the Log_printf and Log_buf APIs from this file.
• Must provide _USE, _INIT, and _DEFINE macros.

In addition, some sinks require initialization. This will be listed in the documentation for the sink implementation. Sinks are closely tied to their associated host side tooling. Since the log statements are not parsed at all by the target code, this must be delegated to a program running on a PC. While the binary format of log records may vary across sink implementations, it is suggested that each log record contain:

1. Timestamp
2. Pointer to metadata string. This will be looked up by the PC side tooling in the out file.
3. Runtime arguments

This is the minimum amount of information needed to decode a log statement.

Usage

This section provides a basic usage summary and a set of examples in the form of commented code fragments. Detailed descriptions of the LOG APIs are provided in subsequent sections.

Synopsis

// Import the Log header
#include <ti/log/Log.h>

// Define your log module and log sink
// If using SysConfig, it will be done automatically, or it can be done
// manually:
// Use helper macro from <ti/log/LogSinkBuf.h> to make a sink instance
// (buffer + config) with 100 entries.
Log_SINK_BUF_DEFINE(MyBufferSink, LogSinkBuf_Type_CIRCULAR, 100);

// Use helper macro from <ti/log/Log.h> to make a module pointing at the new
// sink instance.
// This example will enable all log levels and disable dynamic log levels
Log_MODULE_DEFINE(MyModule, Log_MODULE_INIT_SINK_BUF(MyBufferSink, Log_ALL, LogSinkBuf_printfSingleton, LogSinkBuf_bufDepInjection, NULL))

// Some log sinks may require special initialization to configure hardware.
// Refer to the documentation of the sink you wish to use. For example,
// LogSinkITM must be initialised like this before it can be used:
// LogSinkITM_init();

// Invoke one of the log APIs you want to use for either formatted strings
// or large buffers
Log_printf(MyModule, Log_DEBUG, "The answer is %d", 42);
uint8_t buffer[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
Log_buf(MyModule,
        Log_VERBOSE,
        "The buffer values are:",
        buffer,
        sizeof(buffer));

Examples

• Log printf
• Logging buffers

Log Printf:

The following example demonstrates use of the Log_printf API in code. Log will embed the format string in the call site and will take arguments using varadic arguments.

Log_printf(MyModule, Log_DEBUG, "Hello World!");

The arguments are type-cast to a uintptr_t, which is an unsigned integer type. This limits the supported format specifiers to the following:

• Unsigned decimal integer: %u
• Unsigned hexadecimal integer: %x
• Unsigned hexadecimal integer (capital letters): %X
• Character: %c
• Signed decimal integer for positive values: %i, %d
• Signed octal for positive values: %o

Log Buf:

The following example demonstrates use of the Log buf API in code.

Buf will embed the format string in the call site and will take the buffer as a pointer and length. Buffers are treated as arrays of bytes. The buffer API should only be used when it is necessary to log data that is only available at runtime. It will actually send or store the entire contents of the buffer, so this API should be used sparingly as it is costly in terms of runtime and memory overhead.

uint8_t bufferToLog[] = {0, 1, 2, 3, 4, 5};
Log_buf(ti_log_LogMain,
        Log_DEBUG,
        "The contents of bufferToLog are: ",
        bufferToLog,
        sizeof(bufferToLog));

Log API usage:

For a uniform experience with the logging tool, users are recommended to follow certain guidelines regarding the Log API. Typical use-cases for each API call is described below

Log_printf

Log_printf should be the default mechanism for generating a log statement within an application. Along with the log levels, Log_printf should be used to communicate debug information as a formatted string, which accepts variadic arguments. In this case, a pointer to the string and the arguments themselves are transported by the Log sink.

Log_printf(MyLibraryLogModule,
           Log_ERROR,
           "Library function received illegal argument: %d",
           arg);

Log_buf

When the debug-information to be emitted is a large amount of dynamic data, and is not suitable as an argument to printf, then Log_buf should be used. Log_buf can transport the contents of large dynamic buffers, and as a consequence has a larger overhead and should be used sparsely.

Macro Definition Documentation

Log_TI_LOG_VERSION

#define Log_TI_LOG_VERSION   0.1.0

Log version.

Log_MODULE_DEFINE

#define Log_MODULE_DEFINE	(		name,
			init
	)		const Log_Module LogMod_ ## name = init

Defines a log module.

Log modules are like namespaces for log statements, but also controls the enabled log levels and decides where the log statement is redirected.

Parameters

[in]	name	Name of the log module. Gets prefixed with LogMod_.
[in]	init	Initialization macro from the wanted sink

This is a helper to define Log_Module LogMod_yourName and initialize it with the configuration and functions of the wanted log sink.

For example, you have already used the sink definition macros found in LogSinkITM.h, and now you want to define a new module that uses this:

`Log_MODULE_DEFINE(MyDriver, Log_MODULE_INIT_SINK_ITM(Log_DEBUG | Log_ERROR, LogSinkBuf_printfSingleton, LogSinkBuf_bufSingleton, Null))`

Perhaps you used the LogSinkBuf.h helper macro which needs a unique name per instance and made a separate buffer for critical errors:

`Log_MODULE_DEFINE(MyCritical, Log_MODULE_INIT_SINK_BUF(criticalBuf, Log_ERROR, LogSinkBuf_printfDepInjection, LogSinkBuf_bufDepInjection, NULL)`

You would use this in your application via Log_printf(MyCritical, Log_ERROR, "Oops")

Log_MODULE_DEFINE_WEAK

#define Log_MODULE_DEFINE_WEAK	(		name,
			init
	)		const __weak Log_Module LogMod_ ## name = init

Defines Log module as weak.

If there are multiple modules containing Log statements per library, special care must be taken not to create link-time failures. Whether Log statements from a library are present in the final binary is determined by the library configuration the application links against (instrumented vs uninstrumented). Each Log statement has a link-time dependency on its Log module. Enabling only a subset of Log modules contained within the library will cause any Log statements from other Log modules of that library to fail at link-time. This is avoided by declaring a weak instance of each Log module in C code that is compiled into the library. That way, the SysConfig-generated Log module definitions will override the weak library ones but they are there if SysConfig does not define that particular module.

Parameters

[in]	name	Name of the log module. Gets prefixed with LogMod_.
[in]	init	Initialization value of the Log_Module struct.

Log_MODULE_USE

#define Log_MODULE_USE

(

name

)

extern const Log_Module LogMod_ ## name

Declares a reference to a log module.

Declares that a log module is defined in another file so that it can be used in the file with this macro in it.

Note

This is done automatically for Log and Log_buf statements.

Parameters

[in]

name

Name of the log module. Gets prefixed with LogMod_.

LOG_MODULE_SYM

#define LOG_MODULE_SYM

(

name

)

LogMod_ ## name

Resolves to the symbol name of the log module.

Provided for forward compatibility purposes should you have a need to reference the log module symbol directly.

Log_buf

#define Log_buf	(		module,
			level,
			format,
			data,
			size
	)		_Log_buf_B(module, level, format, data, size)

Log a continuous block of memory.

Use this macro to send out runtime data from the device. This API should be used when the data is non constant and can only be derived at runtime. It is the most intrusive in terms of record overhead and instructions used.

Parameters

[in]	module	Log module that the buffer originated from
[in]	level	Log level of type Log_Level
[in]	format	Restricted format string
[in]	data	Pointer to array of bytes (uint8_t *)
[in]	size	Size in bytes of array to send

Log_printf

#define Log_printf	(		module,
			level,
			...
	)		_Log_printf_B(LOG_OPCODE_FORMATED_TEXT, module, level, __VA_ARGS__)

Log an event with a printf-formatted string.

Use this macro to enable printf style logging. This API offers the most flexibility as the construction of the format string is embedded in the call site of the API. It also supports true variadic arguments.

Parameters

[in]	module	Log module that the buffer originated from
[in]	level	Log level of type Log_Level
[in]	...	Variable amount of arguments. Must match your event or format-string.

Examples:

• Log_printf(MyModule, Log_INFO, "Hello World")
• Log_printf(MyModule, Log_DEBUG, "Age: %d", 42)

Note

All arguments are treated as 32-bit wide and are promoted or truncated accordingly.

Log_MODULE_SET_LEVELS

#define Log_MODULE_SET_LEVELS	(		module,
			levels
	)

Value:

_Log_GUARD_MACRO(                                       \
        Log_MODULE_USE(module);                             \
        if (LogMod_ ## module.dynamicLevelsPtr != NULL) {   \
            *LogMod_ ## module.dynamicLevelsPtr = levels;   \
        }                                                   \
    )

Set a log module's log level bitmask.

If dynamic module log levels is enabled, use this macro to set a specific log module's log level bitmask as a runtime operation.

Parameters

[in]	module	Name of the log module. Gets prefixed with LogMod_.
[in]	levels	Log level bitmask containing zero or more Log_Level

Log_MODULE_GET_LEVELS

#define Log_MODULE_GET_LEVELS

(

module

)

Value:

_Log_GUARD_MACRO(                                       \
        Log_MODULE_USE(module);                             \
        if (LogMod_ ## module.dynamicLevelsPtr != NULL) {   \
            *LogMod_ ## module.dynamicLevelsPtr;            \
        }                                                   \
        else {                                              \
            LogMod_ ## module.levels;                       \
        }                                                   \
    )

Get a log module's log level bitmask.

If dynamic module log levels is enabled, use this macro to get a specific log module's log level bitmask as a runtime operation.

Parameters

[in]

module

Name of the log module. Gets prefixed with LogMod_.

Typedef Documentation

Log_Level

typedef enum Log_Level Log_Level

Log level bitmask values.

One of these enum values should be used in each Log_printf and Log_buf call and one or more should be used in each Log_Module definition.

Log_Module

typedef const struct Log_Module Log_Module

Log_printf_fxn

typedef void(* Log_printf_fxn) (const Log_Module *handle, uint32_t header, uint32_t headerPtr, uint32_t numArgs,...)

Log_printfN_fxn

typedef void(* Log_printfN_fxn) (const Log_Module *handle, uint32_t header, uint32_t headerPtr,...)

Log_buf_fxn

typedef void(* Log_buf_fxn) (const Log_Module *handle, uint32_t header, uint32_t headerPtr, uint8_t *data, size_t size)

Enumeration Type Documentation

Log_Level

enum Log_Level

Log level bitmask values.

One of these enum values should be used in each Log_printf and Log_buf call and one or more should be used in each Log_Module definition.

Enumerator
Log_DEBUG	This should be the default level, reserved to be used by users to insert into applications for debugging. Exported libraries should avoid using this level.
Log_VERBOSE	This level is recommended to be used in libraries to emit verbose information about the operation of the system and system state. This level is typically used for very frequently emitted logs or for very detailed context and state information. Enabling this level in multiple Log_Module may impact the operation of the application or saturate available log sink bandwidth and cause stalls in log record emission.
Log_INFO	This level is recommended to be used in libraries to emit simple information about the operation of the system and the system state. Enabling this level in multiple Log_Module may impact the operation of the application or saturate available log sink bandwidth and cause stalls in log record emission.
Log_WARNING	This level is recommended to be used in libraries to emit warnings. It should typically indicate something unexpected, but not something that automatically leads to system failure. Warnings may be generated during the regular operation of an application. Frequent warnings may indicate a temporary or systemic issue with the system that may require intervention such as a reset or alteration to the software or hardware design. The typical usecase for this level is a recoverable failure such as a failed heap allocation or CRC error in a wireless transmission. Enabling this level in a Log_Module will not impact regular device operation or impact available log sink bandwidth.
Log_ERROR	This level is recommended to be used in libraries to emit errors. Typically, this should be used when something has failed and the system is unable to continue correct operation. Errors are not generated during regular system operation. An error record being generated always indicates an issue with system that requires intervention. The intervention depends on the error but could be a system reset or changes to the software or hardware of the system. Enabling this level in a Log_Module will not impact regular device operation or impact available log sink bandwidth.
Log_ALL	This value enables all levels. Should only be used in Log_Module definitions.
Log_NONE	This value disables all levels when used by itself. Should only be used in Log_Module definitions.