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>
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>
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>
Demultiplexer was not ready to handle case when log message was
incomplete which was followed by other log messages. Such scenario
could occur if there was a fault that happen during logging of
a message. In that case incomplete message was followed by valid
messages (fault report) and this fault report was not handled
because processing was blocked waiting for completion of a
message which preceeded fault report.
Since it is expected that some messages may be incomplete a
garbage collection mechanism is added. When start of a message is
received timestamp is logged and list of incomplete messages
is checked for 'old' messages which persist in incomplete state
for long. When message timeouts it is closed and marked as
invalid. It unblocks processing of following messages.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Add support for standalone mode where data written to STMESP is
decoded on chip to a human-readable strings.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Add module which demultiplexes stream of log message which are
encoded into STPv2 stream by log_frontend_stmesp. There are 3 types of
messages that can be present in the stream:
- Log message (starts with DMTS32, followed by Dx and closed by FLAG)
- Tracepoint (FLAGTS or DMTS32)
- STM HW event (DMTS8 on 0x80 master and 0x00 channel)
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
As there are more frontends coming in the future move existing
frontend to the dedicated directory (like backends).
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
