String location information should only be sent for core which
do not append strings to the log message (PPR, FLPR). Without
this, cpurad was also sending that information and that was
redundant.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
When decoding logs from a remote core with memory that APP can
access, wrong address of an array with string addresses was used.
Log message contains index of a string and APP strings array was
used instead of remote core. Extend STMESP logging so that address
of string array of a remote core is send during startup to the APP
and APP is using this array to decode strings from remote cores.
Bug applies only to PPR and FLPR as APP has no access to RAD memory.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Make Xtensa simulator logging backend depend on more generic
SIMULATOR_XTENSA setting instead of individual SoCs.
Signed-off-by: Tahsin Mutlugun <Tahsin.Mutlugun@analog.com>
Before the fix for #77150 was merged, with LOG_BACKEND_SHOW_COLOR=n and
CONFIG_SHELL_VT100_COLORS=y the shell would still display colors by
enabling the flag in the shell_log_backend.c.
Now, LOG_BACKEND_SHOW_COLOR has to be enabled to allow shell logging
color, but that writes ANSI escape sequences to the log files.
Explicitly disable ANSI color output for the filesystem logging backend.
Signed-off-by: Eric Holmberg <eric.holmberg@northriversystems.co.nz>
This commit moves the assignment of backend IDs from the 'z_log_init'
function to the earlier 'log_core_init' function. This ensures that
backend IDs are assigned before they are used in the 'log_backend_enable'
function, preventing incorrect settings of log dynamic filters.
Signed-off-by: Dong Wang <dong.d.wang@intel.com>
The config LOG_USE_VLA depends on that MISRA_SANE is not set.
Unfortunately the IAR toolchain can't handle vla:s inside a
statement, which the LOG_USE_VLA macro does.
I've added a new, hidden config to check if vla is ok inside
statements, SUPPORT_VLA_IN_STATEMENTS. Default is always y, but
a toolchain can override it so that VLA is not used by
Z_LOG_MSG_ON_STACK_ALLOC.
Signed-off-by: Lars-Ove Karlsson <lars-ove.karlsson@iar.com>
The logging thread is usually woken up by a timer, if the timer
period is longer than 10ms, log_flush() can iterate multiple times
needlessly, while waiting for the next timer. Instead wake up the
logging thread to let it flush the queue immediately. Besides a
hard-coded polling period of 10ms is too long for some applications,
make it a Kconfig parameter.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Typically, when shell logging backend is used user wants to get
logs on shell instances so do not enable raw RTT log backend in
that case. When raw backend is enabled then initial logs go to
RTT backend and they are not visible on shell which starts later
as it requires additional thread.
It can be assumed that when RTT backend is used it will be
explicitly enabled by the user.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
The BLE acronym is not an official description of Bluetooth
LE, and the Bluetooth SIG only ever refers to it as Bluetooth
Low Energy or Bluetooth LE, so Zephyr should as well.
This commit does not change any board or vendor specific
documentation, and the term BLE may still be used in those.
It will be up to the vendors to update it if they want,
since many of them are using the term BLE in their
products.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The 'log_flush()' function is used to wait for all pending log messages
to be processed by the background thread. This is performed by polling
the 'log_data_pending()' function, which scans all available buffers.
The log core already provides a 'buffered_cnt' variable that keeps track
of the number of pending messages. This variable is updated atomically
and could be a more efficient implementation for that check.
This commit moves the 'buffered_cnt' decrement _after_ the message
processing and buffer release, to ensure that the variable reflects
the number of pending messages at any moment in time.
The 'log_data_pending()' function is then replaced with a direct check
of the 'buffered_cnt' variable.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
In order to check if the desired log file exists, the backend would open
the directory, then go through all the files seeing if one of them matches
the correct filename. Simplify to just `fs_stat` the file instead.
This has the added side effect of lowering the time spent checking if the
file exists after every log. Some quick testing revealed the time spent
checking went down from ~150-300ms to ~10ms (on my specific board, with a
nRF9160 writing to a LittleFS on external flash).
Signed-off-by: Kamil Krzyzanowski <kamnxt@kamnxt.com>
The previous behavior was to call `fs_sync` on the file after every log
item written. In many cases, log messages come in bursts, and `log_core`
already operates in batches, configurable using
`CONFIG_LOG_PROCESS_THREAD_SLEEP_MS` and
`CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD`. Once the batch is done, the
backends get notified with `LOG_BACKEND_EVT_PROCESS_THREAD_DONE` if any
logs were processed. This is a nice time to `fs_sync` the written changes.
This change both speeds up the time spent writing logs and reduces the
amount of block erases done on the flash, as the previous implementation
erased blocks after each individual log message.
Signed-off-by: Kamil Krzyzanowski <kamnxt@kamnxt.com>
Convert testing of the logging backend for file-system to include the
full implementation.
Need to disable logging and just include the unit under test to make
this simpler.
The API functions for the backend can then be called on the backend
object.
Signed-off-by: Joakim Andersson <joerchan@gmail.com>
For backends that do not autostart themselves, initialize
& enable them on `log backend <log_backend_*> go`, so
that they function properly.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
The `id` is basically a compile-time constant. Setting it every
time the backend is enabled is unnecessary. Instead, set it on
`z_log_init()` regardless of whether or not it requires to be
`autostart`ed.
Fixes an issue where the `filter_get`/`filter_set`
accessed the wrong index and displayed the wrong log level when
user accesses the status of an uninitialized backend via:
`log backend <uninitialized_backend> status`.
Also fixes an issue when user tries to list the backends via:
`log list_backends`, where all uninitialized backends will have
ID = 0.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
Macro was missing a break when single argument with non 32 bit
word argument was detect. Because of that, there were two
logging messages created for a single log entry.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Ensure all pending log messages are processed by the log processing
thread when log_flush is called, blocking the caller until done.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
The debug printing feature seems to be broken by design - not only in a
default configuration it would trigger endless logging loop (as printk
is piped through logging subsys), it also doesn't work well with
deferred logging (additional artifacts in the output).
Since similar effect can be achieved by enabling any other logger
backend, which should receive the same data as the websocket one, simply
remove it.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case the log message length exceeded the websocket buffer size, the
backend would drop the overflowing character, instead of sending it as a
part of the next message.
Rework the ws_console_out() logic a bit to prevent that.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The log output function registered for the logger backend is expected to
return the number of bytes processed, but currently it returns the TX
retry count. This commit fixes it. In case data could only partially be
sent, respective bytes count is returned. In case of TX error, the bytes
are assumed dropped to prevent busy looping in the logger.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Increase the maximum value of LOG_BUFFER_SIZE from 64 KB to 1 MB
to accommodate varying device requirements.
Signed-off-by: Jungo Lin <jungolin.tw@gmail.com>
Logging with STMESP frontend is using custom logging header feature.
Put that specific header file in a custom path which is added to the
build only if that logging frontend is used.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Add support for handling optimized short log messages (aka turbo logs).
There are 2 types of turbo log messages:
- No arguments. D16MTS is used for that on channel > 32768
- One numeric argument. DM16 followed by D32MTS is used.
Additionally, in order to be able to get source name for log messages
coming from owned by cpuapp co-processors (PPR and FLPR) there must
be a way of passing location of constant source data from PPR/FLPR to
cpuapp which handles ETR data. This method is added in the commit as
well. PPR/FLPR sends D32M during the boot with address of constant
source data section. Demultiplexer stores those addresses and it is
able to retrieve source name for log messages from PPR/FLPR.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Add 'turbo' logging feature. When enabled, short logs (no argument
or one numeric, 32 bit argument) are handled in a special way that
is much faster than the default one (5-10x faster). Additionally,
there is an option to remove all other logs from the system which
allows to not include almost any logging framework code in the
binary (~170 bytes of code is needed). It may be especially
valueable for memory constraint targets (ppr, flpr) where with
only 170 byte of code (+code for each log message) we can provide
limited formatted string logging support.
'Turbo' logging is using following to achieve that:
- logging strings are put into a memory section and additional
memory section is created which holds addresses of those strings.
Index in that array is used to identify a string (32 bit address
is encoded into a smaller number, 15 bits is more than enough).
This index is used for a STMESP register set (there are 2^16
available). So STMESP channel encodes string.
- Logging level is stringified and prepended to a string
- Source ID is encoded by using DM16 (so far not used).
- Log without arguments is written as DMTS16
- Log with one argumetn is written as DM16+DMTS32
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Set initial filtering settings in the log core init only if
runtime filtering is enabled. It saves few bytes when runtime
filtering is off.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
now that CONFIG_POSIX_C_LANG_SUPPORT_R will
add a custom implementation for gmtime_r() if that
is not provided by the toolchain, we can simply depend on
that, instead of using out own.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
In order to support error and warning message coloring
LOG_BACKEND_SHOW_COLOR must be set. Allow setting it for
customized cases.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
The production version of the nRF54H20 SoC is now available, so remove
the initial Engineering B (EngB) preview version.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Add an alternate message output option in which messages are
ended with an additional zero data byte with marker and timestamp.
Can be used to maintain compatibility with certain decoders.
Signed-off-by: Juha Sunnari <juha.sunnari@nordicsemi.no>
There was a kconfig option used in v1 logging to get clean
output in the immediate mode. It was lost during the transition
to v2 but Kconfig remained. Adding spin_lock to log processing
to ensure that log messages are not interleaved in the output
in the immediate mode.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
When shell is integrated with the logging frontend then pointer to
the logging backend in the shell structure is null. When null pointer
is found assume that it is a shell instance with logging frontend
integration and use frontend in the logging commands.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Allow logging output to websocket console. Requires that
websocket shell backend and websocket HTTP server support
is also enabled.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
When CONFIG_LOG_OUTPUT is set, it indicates that logging strings
are formatted by the application (using log_output module). It is
not needed when backend works in the dictionary mode. So far
LOG_OUTPUT was set also when dictionary mode was used and that
prevented removing of the logging strings from binary which is
an important feature of the dictionary logging.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Move log_output_flush and log_output_write (renamed internal
buffer_write() function) to the header as inline functions.
Those function are used by log_output_dict.c and there are cases
when log_output.c is not compiled in.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Building the net logger backend with IPv4 only gives the following
warning:
log_backend_net.c:116:31: warning: array subscript 'struct sockaddr[0]'
is partly outside array bounds of 'struct sockaddr_in[1]'
[-Warray-bounds] local_addr->sa_family = server_addr.sa_family;
hence assign the address family directly to sockaddr_in/6 structs.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
There are many places where source_id is retrieved and it
depends on runtime filtering being enabled. So far it was
all exposed but lets encapsulate that into a helper function.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Currently we can assume that flpr and ppr cores are always owned by
cpuapp. In that case, cpuapp (which processes ETR buffer content) has
access to the memory where logging strings from ppr and flpr are
located. Those strings do not need to be appended to the message
which is written to the STM (in case of standalone configuration).
This approach reduced logging time, e.g. logging a message with
one argument takes 1.8us on cpuapp and 6.3us on cpurad.
This setting applies only to the case when cpuapp is the owner
of those co-oprocessors and shall be updated if that becomes
configurable but currently there are no means to detect core
owner.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
This adds a timestamp format mode, that includes the date, which is
usefull, when using realtime for the logging timestamp.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
this way CONFIG_LOG_OUTPUT_FORMAT_CUSTOM_TIMESTAMP
only uses the custom timestamps for
logs that are not send via syslog.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
