Diagnostic Log and Trace (DLT)

The synchronous and non-reentrant function Dlt_Init (service ID 0x01, available via header file Dlt.h) initializes the module Diagnostic Log and Trace (DLT) in the Classic Platform [SWS_Dlt_00239]. Via parameter config, it accepts a pointer to the module-specific configuration structure of type Dlt_ConfigType and returns no return value [SWS_Dlt_00239].

Specific boundary conditions apply to the call context and the temporal interaction with other BSW modules:

• Initialization order: The DLT module uses the NVRam Manager and must be initialized very late in the startup phase of the ECU [SWS_Dlt_00239]. Calling the function Dlt_Init must strictly take place only after full initialization of the NVRam Manager [SWS_Dlt_00239].
• Persistent data: If the configuration parameter DltGeneralNvRAMSupport is set to TRUE, the DLT module in Dlt_Init uses the interface NvM_ReadBlock of the NVRAM Manager to restore persistent values for required variables [SWS_Dlt_00453].
• Buffer processing: As soon as the module has been initialized by Dlt_Init and the optional timer DltGeneralStartUpDelayTimer has expired, all log and trace data buffered in the meantime are processed and transmitted according to the specification [SWS_Dlt_00005].

Since the function is specified as non-reentrant, the calling context must ensure that Dlt_Init is not re-entered concurrently or in an interrupting manner during execution [SWS_Dlt_00239].

The synchronous and reentrant function Dlt_SendTraceMessage serves basic software modules (BSW) as well as software components (SW-C) for transmitting trace parameters to the Dlt module [SWS_Dlt_00243].

Parameters and call context

Upon invocation, the module or port identifier via sessionId, metadata for message filtering via traceInfo, and the payload buffer via traceData along with length specification traceDataLength are passed [SWS_Dlt_00243]. The module can already buffer trace messages even if Dlt has not yet been initialized [SWS_Dlt_00003].

Return Values and Error Handling

The service signals the status via specific return values [SWS_Dlt_00243]:

• E_OK: The operation was executed successfully.
• DLT_E_MSG_TOO_LARGE: The message exceeds the allowed size of all assigned log channels.
• DLT_E_NO_BUFFER: Insufficient buffer memory; the message cannot be buffered for at least one log channel.
• DLT_E_UNKNOWN_SESSION_ID: The passed sessionId is unknown to the module.

Interaction with Hook Functions

Since Dlt_SendTraceMessage is specified as an interface for SW-Cs, an equivalent internal implementation [SWS_Dlt_00285] exists for generated hook functions, which sends trace messages in non-verbose mode [SWS_Dlt_00277].

The synchronous and reentrant function Dlt_SendLogMessage (service ID 0x03) serves basic software (BSW) modules and software components (SW-C) as a standardized interface for sending log messages [SWS_Dlt_00241]. The call is made via the header file Dlt.h, and due to reentrancy, the function is designed for concurrent use [SWS_Dlt_00241].

When calling the function, four passed parameters are required, while no output parameters are used [SWS_Dlt_00241]:

• sessionId: Represents the session ID. For SW-Cs, this parameter is invisible as a port-defined argument value, whereas BSW modules pass their module number directly.
• logInfo: Pointer to a constant structure containing the relevant metadata for filtering the log message.
• logData: Pointer to the byte array containing the data to be logged, which forms the actual payload of the message.
• logDataLength: Numerical length of the data buffer logData.

Error handling is performed directly via the return value of type Std_ReturnType, which indicates the success of the operation or specific error conditions [SWS_Dlt_00241]:

• DLT_OK: The log message was successfully accepted and processed.
• DLT_E_MSG_TOO_LARGE: The message exceeds the maximum allowed buffer size for all assigned log channels.
• DLT_E_NO_BUFFER: The message could not be buffered on any of the assigned log channels.
• DLT_E_UNKNOWN_SESSION_ID: The passed session ID is invalid or unknown to the module.

use

The synchronous function Dlt_UnregisterContext (service ID 0x16) is provided via the header file Dlt.h and must be called when a software module is stopped [SWS_Dlt_00769]. It serves to unregister a previously registered context of an application.

The function expects three input parameters [SWS_Dlt_00769]:

• sessionId: Module number; corresponds to the module ID within the BSW or the port-specifically defined argument value within a software component (SW-C) [SWS_Dlt_00769].
• appId: The identifier of the parent application (Application ID) [SWS_Dlt_00769].
• contextId: The identifier of the context to be unregistered (Context ID) [SWS_Dlt_00769].

Return Values and Error Handling

The return value of type Std_ReturnType provides information about the result of the execution [SWS_Dlt_00769]:

• E_OK: The requested operation was completed successfully [SWS_Dlt_00769].
• DLT_E_CONTEXT_NOT_YET_REG: The context of the software module was not registered beforehand [SWS_Dlt_00769].
• DLT_E_UNKNOWN_SESSION_ID: The passed session ID is unknown [SWS_Dlt_00769].

Concurrency and Limitations

The function is specified as reentrant and behaves synchronously [SWS_Dlt_00769]. Calling modules must ensure that the passed session ID is valid and that the context was actually registered before termination in order to avoid errors during deregistration [SWS_Dlt_00769].

Usage and Call Context

The synchronous interface Dlt_DetForwardErrorTrace with the service ID 0x07 serves to forward reported development errors from the Default Error Tracer (DET) to the Dlt module [SWS_Dlt_00432]. The Dlt module provides this service to ensure the required fan-out capability of the DET for error reports [SWS_Dlt_00430]. The declaration of this C function is included via the header file Dlt_Det.h [SWS_Dlt_00432].

Parameters and interface specification

The function accepts four mandatory input parameters and defines neither return values nor output parameters [SWS_Dlt_00432]:

• moduleId: Module ID of the calling software module in which the error occurred.
• instanceId: Identifier of the index-based module instance (counting starts at 0; single-instance modules pass 0).
• apiId: Identifier of the affected API service (defined in the specification of the calling module).
• errorId: Identifier of the detected development error (defined in the specification of the calling module).

Concurrency and Error Handling

Execution occurs synchronously with the calling error detection. As a non-reentrant function (Non Reentrant), the interface strictly requires that concurrent executions are avoided on the caller side [SWS_Dlt_00432]. Specific error codes, error feedback, or separate DET or DEM messages are not provided for this service in the specification [SWS_Dlt_00432].

The synchronous function Dlt_SetTraceStatus serves to set the trace status for a specific tuple of Application ID and Context ID [SWS_Dlt_00254]. It is defined via header file Dlt.h and has the service ID 0x09 [SWS_Dlt_00254].

use

Three input parameters are required for the call [SWS_Dlt_00254]:

• appId: The ID of the software component (type Dlt_ApplicationIDType).
• contextId: The ID of the context (type Dlt_ContextIDType).
• newTraceStatus: The trace status to be newly set as a boolean value (type boolean).

Error Handling and Return Values

The function synchronously returns a status of type Std_ReturnType [SWS_Dlt_00254]:

• E_OK: No error occurred and the status was accepted successfully.
• E_NOT_OK: The trace status could not be changed. Specific DET error messages are not mentioned in the function specification (Interpretation: An error is presumably present in case of invalid identifiers or an incorrect module state). Question Q-77e190707462c8f1 (open)

Concurrency and Limitations

The interface is specified as non-reentrant (Non Reentrant) [SWS_Dlt_00254]. Therefore, it must not be executed concurrently or in an interrupting manner without appropriate synchronization by the caller.

use

The function Dlt_StoreConfiguration ([SWS_Dlt_00736]) serves to save the current Dlt configuration to non-volatile memory (NvRAM). Saving takes place internally via a synchronous call of interface NvM_WriteBlock() of the NVRAM Manager ([SWS_Dlt_00736]). The API is provided via header Dlt.h with service ID 0x1a.

The function has the signature Std_ReturnType Dlt_StoreConfiguration(void) and processes neither input, output, nor input/output parameters ([SWS_Dlt_00736]).

Error Handling and Return Values

As a synchronous service, the function immediately returns a status code of type Std_ReturnType to the caller ([SWS_Dlt_00736]):

• E_OK: The configuration was transferred without errors to the NvRAM ([SWS_Dlt_00736]).
• E_NOT_OK: An error occurred while saving the Dlt configuration ([SWS_Dlt_00736]).
• DLT_E_NOT_SUPPORTED: The service for configuration saving is not supported by the module ([SWS_Dlt_00736]).

Concurrency and Limitations

According to [SWS_Dlt_00736], Dlt_StoreConfiguration is specified as non-reentrant (Non Reentrant). The function therefore must not be executed concurrently from different tasks or contexts, so that a sequential execution must be ensured on the caller side.

use

The synchronous function Dlt_ResetToFactoryDefault is provided via header Dlt.h and accepts no passed parameters [SWS_Dlt_00739]. Its primary purpose is resetting the Dlt runtime configuration: It resets the log level and the trace status to the persistently stored default values [SWS_Dlt_00739]. If NvRAM support is additionally activated in the Dlt module, calling it causes the complete deletion of all Dlt values stored in the NvM [SWS_Dlt_00739].

Return Values and Error Handling

The result of the operation is signaled synchronously via the return value of type Std_ReturnType [SWS_Dlt_00739]:

• E_OK: The configuration was successfully reset to default values [SWS_Dlt_00739].
• E_NOT_OK: Resetting the configuration failed [SWS_Dlt_00739].

Specific DET or DEM error messages are not defined for this service in the present specification scope.

Concurrency and Limitations

The function is specified as non-reentrant (Non Reentrant) (service ID 0x06) [SWS_Dlt_00739]. A concurrent or interrupting call from different tasks or contexts is therefore not permissible and must be prevented by the caller.

The function Dlt_RxIndication serves for the indication of a received PDU from a lower-layer communication interface module to the DLT module [SWS_Dlt_00272]. It is available via the header Dlt.h and has the service ID 0x42 [SWS_Dlt_00272].

The call occurs with synchronous semantics and provides no return value (void) [SWS_Dlt_00272]. Two input parameters are passed to the function:

• RxPduId: Identifier of the received PDU (of type PduIdType) [SWS_Dlt_00272].
• PduInfoPtr: Pointer to a structure of type PduInfoType. This contains the length of the received PDU (SduLength), a pointer to the buffer with the PDU payload (SduDataPtr), and associated metadata of the PDU [SWS_Dlt_00272].

Regarding concurrency and execution context, the function is reentrant for different PDU IDs, but not reentrant for the same PDU ID [SWS_Dlt_00272]. Consequently, the calling lower-layer module must not have the same RxPduId processed concurrently, while parallel calls with different PDU IDs are permissible [SWS_Dlt_00272].

According to [SWS_Dlt_00754], the synchronous function Dlt_TriggerTransmit serves to copy SDU data into a provided buffer upon request of an underlying layer. It is declared in Dlt.h and has the service ID 0x41.

The following parameters are passed upon the call:

• TxPduId: Identifier of the SDU whose transmission is requested.
• PduInfoPtr: Pointer to a structure of type PduInfoType. Via SduDataPtr, the caller passes the destination buffer and via SduLength the maximum available buffer size.

Within the function, the module checks according to [SWS_Dlt_00754] whether the available data fits into the passed buffer size:

• If the data fits, the function copies the payload data to SduDataPtr, updates SduLength with the number of actually copied bytes, and returns E_OK.
• If the buffer is insufficient, the function returns E_NOT_OK without modifying PduInfoPtr.

If E_NOT_OK is returned, no SDU data was copied. In this case, the caller must not continue to use PduInfoPtr, as it may point to invalid data or be a NULL pointer [SWS_Dlt_00754].

With respect to concurrency, Dlt_TriggerTransmit is reentrant for different PDU IDs, but not reentrant for the same TxPduId [SWS_Dlt_00754].

Usage and Call Context

The function Dlt_TxConfirmation serves as a confirmation interface of the lower layer communication interface module to the module Diagnostic Log and Trace (DLT) [SWS_Dlt_00273]. It synchronously informs the DLT module whether a previously requested PDU could be transmitted successfully or whether the transmission failed [SWS_Dlt_00273]. The function has the service ID 0x40 and is provided via header file Dlt.h [SWS_Dlt_00273].

The interface has no return value (void) and expects two passed parameters [SWS_Dlt_00273]:

• TxPduId: The identifier of the transmitted PDU of type PduIdType.
• result: The transmission status of type Std_ReturnType; here, E_OK signals successful transmission and E_NOT_OK signals failure of the PDU transmission.

Error Handling and Concurrency

Explicit error handling with error return values or specific DET or DEM messages is not specified for this call; the failure of a transmission process is communicated to the DLT module purely via the parameter value result = E_NOT_OK [SWS_Dlt_00273].

A differentiated reentrancy condition applies to execution: Dlt_TxConfirmation is reentrant for different PDU IDs, but not reentrant for the same PDU ID [SWS_Dlt_00273]. Calling drivers or interfaces must therefore ensure that concurrent calls with an identical TxPduId are precluded, whereas confirmations for different PDUs may arrive concurrently.

The function Dlt_TpTxConfirmation serves as a synchronous confirmation function of the Dlt module after sending a transport I-PDU [SWS_Dlt_00756]. It is available via the header file Dlt.h with the service ID 0x48 [SWS_Dlt_00756].

Usage and Semantics

The call occurs after an I-PDU has been transmitted on the respective network [SWS_Dlt_00756]. The function has the signature void Dlt_TpTxConfirmation (PduIdType id, Std_ReturnType result) and returns no return value [SWS_Dlt_00756]:

• id (input parameter, type PduIdType): Unique identification of the transmitted I-PDU [SWS_Dlt_00756].
• result (input parameter, type Std_ReturnType): Indicates the transmission status and shows whether sending the I-PDU was successful or failed [SWS_Dlt_00756].

Concurrency and Error Handling

The specification identifies Dlt_TpTxConfirmation as synchronous and reentrant (Reentrant) [SWS_Dlt_00756]. Specific DET or DEM error codes are not defined for this service; error handling regarding the send process relies on evaluating the parameter result [SWS_Dlt_00756]. In the system context, the call is typically expected to be initiated by an underlying transport layer after completion of the PDU transmission. Question Q-0e5ab7c285316701 (open)

Usage and Semantics

The synchronous and reentrant function Dlt_CopyTxData serves to retrieve transmit data of an I-PDU segment (N-PDU) from the Dlt module [SWS_Dlt_00516]. Via id, the I-PDU to be transmitted is specified, while info provides the destination buffer (SduDataPtr) and the requested byte length (SduLength) [SWS_Dlt_00516]. Passing SduLength = 0 (where SduDataPtr may be passed as NULL_PTR) allows transmitting pure state changes via retry or querying the remaining data amount in the transmit buffer [SWS_Dlt_00516]. Via the output parameter availableDataPtr, the function reports the data amount still available in the Tx buffer, which enables, for example, TP modules with dynamic payload length (such as FrIsoTp) to dimension subsequent segments [SWS_Dlt_00516].

Confirmation and error recovery

Acknowledgment or repeated transmission is controlled via the pointer retry [SWS_Dlt_00516]:

• If retry is a NULL_PTR, the copied data may be discarded from the buffer immediately after the copy process [SWS_Dlt_00516].
• If TpDataState indicates the value TP_CONFPENDING, previously copied data must remain in the buffer for possible error recovery [SWS_Dlt_00516].
• With TP_DATACONF, all data transmitted before the call is considered confirmed and can be released [SWS_Dlt_00516].
• With TP_DATARETRY, the module resumes copying starting from the byte offset passed in TxTpDataCnt [SWS_Dlt_00516].

Return values and constraints

The result of the request is reported as BufReq_ReturnType [SWS_Dlt_00516]:

• BUFREQ_OK: Data was completely copied into the destination buffer as requested [SWS_Dlt_00516].
• BUFREQ_E_BUSY: The requested amount of data is not available; no data was copied, a later retry is permissible [SWS_Dlt_00516].
• BUFREQ_E_NOT_OK: Request failed; no data was copied [SWS_Dlt_00516].

The interface is available via Dlt.h and designed to be reentrant [SWS_Dlt_00516]. The call context is likely to typically reside in a lower-layer transport protocol module during segmented transmission. Question Q-a81c439e73e0acc0 (open)

The synchronous and reentrant function Dlt_StartReception is called at the start of receiving an N-SDU, which can be received as a single frame (SF) or fragmented across multiple N-PDUs [SWS_Dlt_91006]. It serves to initiate the transport connection in the Dlt module and provide the available receive buffer [SWS_Dlt_91006].

Via parameter id, the received I-PDU is identified, while info conveys payload and metadata of the first frame or is set to NULL_PTR if neither data nor metadata are present [SWS_Dlt_91006]. Via TpSduLength, the total length of the N-SDU is passed; if the function is called with a length of 0, it returns the currently maximum available buffer size via bufferSizePtr [SWS_Dlt_91006]. The transport protocol uses the value from bufferSizePtr to calculate the block size (BS) [SWS_Dlt_91006].

If the connection is accepted, the function returns BUFREQ_OK; if not enough buffer is available for the requested size, bufferSizePtr indicates a buffer size of 0 to continue reception [SWS_Dlt_91006]. If the connection is rejected, BUFREQ_E_NOT_OK aborts the reception, and if overall memory is insufficient, BUFREQ_E_OVFL is reported; in both error cases, bufferSizePtr remains unchanged [SWS_Dlt_91006].

The function Dlt_TpRxIndication serves as a synchronous reception indication after an I-PDU has been received via the TP API [SWS_Dlt_91007]. It is declared in the header file Dlt.h and has the service ID 0x45 [SWS_Dlt_91007].

Usage and Parameters

Passing to the DLT module takes place via two input parameters, with the function returning no return value [SWS_Dlt_91007]:

• id (type PduIdType): Designates the identification of the received I-PDU [SWS_Dlt_91007].
• result (type Std_ReturnType): Indicates the result of the reception and shows whether the transmission was successful [SWS_Dlt_91007].

Concurrency and Limitations

The interface is defined as synchronous and reentrant [SWS_Dlt_91007]. There are neither input/output nor pure output parameters [SWS_Dlt_91007].

Error Handling and Interaction

The result of the transport is signaled to the DLT module exclusively via the argument result; specific error codes, DET or DEM messages are not specified [SWS_Dlt_91007].

Interpretation: The call is likely to be made by an underlying transport protocol component as soon as a DLT message has completely arrived or the transmission aborts [SWS_Dlt_91007]. Question Q-7d9c8564a2404acf (open)

Usage and Semantics

The synchronous function Dlt_CopyRxData is called to pass received data of an I-PDU segment (N-PDU) to the upper layer [SWS_Dlt_91008]. Each call provides the respective next part of the I-PDU data, with the remaining buffer size being written to the memory location referenced via bufferSizePtr [SWS_Dlt_91008]. The declaration is available via the header Dlt.h [SWS_Dlt_91008].

Parameters and Buffer Query

Via the input parameter id, the received I-PDU is identified [SWS_Dlt_91008]. The pointer info provides the source buffer via SduDataPtr as well as the number of bytes to copy via SduLength [SWS_Dlt_91008]. If SduLength is passed with the value 0, the call serves purely to query the buffer currently available in the upper module; in this case, SduDataPtr may be a NULL_PTR [SWS_Dlt_91008]. The output parameter bufferSizePtr returns the receive buffer size still free after the copy operation [SWS_Dlt_91008].

Concurrency and return values

The function is designed to be reentrant and has the service ID 0x44 [SWS_Dlt_91008]. The return value of type BufReq_ReturnType signals the result of the copy operation: Upon successful data acceptance, the service returns BUFREQ_OK, whereas in case of error BUFREQ_E_NOT_OK is reported [SWS_Dlt_91008].

Usage and Call Context

According to specification [SWS_Dlt_91005], the function Dlt_TxFunction is defined as a service with the service ID 0x80 and is available via the header SchM_Dlt.h. Its interface signature is void Dlt_TxFunction (void) [SWS_Dlt_91005]. As an interpretation, the declaration in SchM_Dlt.h indicates that the call is performed by the BSW scheduler in the context of a cyclic task and should not be called directly by application software components.

Parameters and Return Values

According to [SWS_Dlt_91005], the function takes no input parameters and returns no return value (void). By its name, the function is likely responsible for the cyclic processing and transmission of pending Dlt transmit messages. Question (open) Since no return values are specified, error handling is presumably purely module- or state-internal.

restrictions

Since the payload does not contain any information on reentrancy or specific development errors, call intervals and task assignments must be coordinated via the schedule manager configuration. Further error codes or DET entries are not identified in [SWS_Dlt_91005].