FlexRay Driver (Fr)

The synchronous function Fr_Init serves to initialize the FlexRay driver (Fr) according to [SWS_Fr_00032]. It is declared via the header file Fr.h and has the service ID 0x1c [SWS_Fr_00032]. The interface expects Fr_ConfigPtr of type const Fr_ConfigType* as the only input parameter [SWS_Fr_00032]. This pointer references a driver-dependent configuration structure that provides all information required for the subsequent operative operation of the FlexRay driver [SWS_Fr_00032]. The function has neither input/output parameters nor output parameters and provides no return value (void) [SWS_Fr_00032].

Regarding concurrency and constraints, Fr_Init is specified as non-reentrant (Non Reentrant) [SWS_Fr_00032]. Calls must therefore under no circumstances occur in parallel or nested. Since the passed configuration structure contains all fundamental data for further operation, initialization is typically performed sequentially during the start-up phase of the overall system before other module services are called [SWS_Fr_00032]. Question Q-a208c696fbb083d4 (open)

Error handling via specific error codes or status feedback is not provided in the service definition [SWS_Fr_00032]. Further requirements, such as notifications to DET or DEM, are not documented in the present dataset.

The synchronous function Fr_ControllerInit serves to initialize a FlexRay Communication Controller (FlexRay CC) in the context of the FlexRay driver [SWS_Fr_00017]. It is declared in the header file Fr.h and has the service ID 0x00 [SWS_Fr_00017]. Via the input parameter Fr_CtrlIdx of type uint8, the index of the controller to be initialized is passed [SWS_Fr_00017].

As return value, the function provides the status Std_ReturnType [SWS_Fr_00017]:

• E_OK: The API call completed successfully [SWS_Fr_00017].
• E_NOT_OK: The call was aborted prematurely due to errors that occurred [SWS_Fr_00017].

Detailed error codes and notifications to DET or DEM are not listed in the specified interface scope [SWS_Fr_00017].

Regarding concurrency, the function is classified as non-reentrant for the same hardware unit (Non Reentrant for the same device) [SWS_Fr_00017]. Therefore, a call for the same controller index Fr_CtrlIdx must not occur simultaneously; parallel calls for different controllers, however, are presumably permitted [SWS_Fr_00017]. Question Q-5bbbba38e8530b43 (open) Since no input and output parameters (inout/out) are defined, initialization is purely state-based in the driver [SWS_Fr_00017].

The function Fr_StartCommunication serves to start FlexRay communication on a specified controller [SWS_Fr_00010]. The interface is available via the header file Fr.h [SWS_Fr_00010].

use

The call is made asynchronously, passing the parameter Fr_CtrlIdx (Service ID 0x03), which specifies the index of the FlexRay communication controller within the driver context [SWS_Fr_00010]. As return value, the function provides a status of type Std_ReturnType [SWS_Fr_00010]:

• E_OK: The API call ended successfully [SWS_Fr_00010]. Interpretation: Due to the asynchronous semantics, this likely signifies the successful acceptance of the start command, while the actual connection establishment proceeds subsequently. Question Q-fabca57ea7d32a05 (open)
• E_NOT_OK: The API call was aborted due to errors [SWS_Fr_00010].

Concurrency and Limitations

For the same FlexRay controller, Fr_StartCommunication is specified as non-reentrant [SWS_Fr_00010]. For different controller instances, however, the call is reentrant. Specific development errors (DET), error notifications (DEM), or further dependencies are not contained in the available specification data.

use

The function Fr_AllowColdstart serves to call the Controller Host Interface command ALLOW_COLDSTART on the FlexRay Communication Controller [SWS_Fr_00114]. The declaration is provided via the header file Fr.h; the service has the Service ID 0x23 [SWS_Fr_00114]. The input parameter Fr_CtrlIdx specifies the index of the FlexRay controller to be addressed within the FlexRay driver [SWS_Fr_00114]. The call is executed asynchronously [SWS_Fr_00114].

Error Handling and Return Values

The function returns a status of type Std_ReturnType [SWS_Fr_00114]:

• E_OK: The API call ended successfully [SWS_Fr_00114].
• E_NOT_OK: The API call was aborted due to errors [SWS_Fr_00114].

Specific error causes or notifications to DEM or DET are not listed separately for this service in the functional specification [SWS_Fr_00114].

Concurrency and Limitations

The interface is non-reentrant for the same controller instance (Non Reentrant for the same device) [SWS_Fr_00114]. Calls with the same parameter Fr_CtrlIdx must therefore not occur in parallel or preemptively [SWS_Fr_00114]. Interpretation: Due to the asynchronous execution semantics, the return value E_OK presumably only acknowledges the driver's acceptance of the CHI command, whereas the controller-internal state change takes place with a time delay [SWS_Fr_00114]. Question Q-e5c407f32c449510 (open)

Usage and Operation

The function Fr_AllSlots serves to issue the CHI (Controller Host Interface) command ALL_SLOTS to the addressed FlexRay communication controller [SWS_Fr_00516]. It is provided via the header Fr.h and has the service ID 0x24 [SWS_Fr_00516].

As an input parameter, the function expects Fr_CtrlIdx, which indicates the index of the affected FlexRay controller within the context of the FlexRay driver [SWS_Fr_00516]. Execution occurs asynchronously [SWS_Fr_00516]. The return value E_OK signals that the API call completed successfully, whereas E_NOT_OK indicates an abort due to errors [SWS_Fr_00516]. Due to the asynchronous semantics, E_OK presumably merely confirms the successful acceptance or triggering of the CHI command and not the completed hardware response of the controller (interpretation). Question Q-c526e3b174a4b44a (open)

Error Handling and Concurrency

If execution fails, the call aborts with the return value E_NOT_OK [SWS_Fr_00516]. Specific error causes or DET/DEM notifications are not named in the specification of this element.

Regarding reentrancy, Fr_AllSlots is specified as non-reentrant for the same controller (Non Reentrant for the same device) [SWS_Fr_00516]. Concurrent calls for the same controller instance must therefore be avoided by higher layers. Parallel calls for different controller instances, on the other hand, are likely to be permissible (interpretation). Question (open)

The function Fr_HaltCommunication serves to initiate the halting of communication on a FlexRay communication controller by executing the CC CHI command 'DEFERRED_HALT' [SWS_Fr_00014].

Usage and Parameters

The call is made asynchronously and is provided via the header Fr.h (service ID 0x04) [SWS_Fr_00014]:

• Fr_CtrlIdx (input parameter): Determines the index of the FlexRay communication controller to be addressed within the FlexRay driver [SWS_Fr_00014].
• Return value (Std_ReturnType): Returns E_OK if the function call completed successfully, or E_NOT_OK if the call was aborted due to errors [SWS_Fr_00014].

Concurrency and Limitations

Regarding call context and concurrency, Fr_HaltCommunication is non-reentrant with respect to the same device (Non Reentrant for the same device) [SWS_Fr_00014]. Consequently, no concurrent or overlapping call may occur for the same controller index. Calls for different controller instances, however, are permitted.

Error handling

If an error occurs during the call, the function aborts execution and signals this via the return value E_NOT_OK [SWS_Fr_00014]. Detailed error messages are not listed for this function in the specification scope.

The synchronous function Fr_AbortCommunication aborts ongoing communication by executing the Controller Host Interface command (CHI command) FREEZE on the specified FlexRay communication controller (CC) [SWS_Fr_00011].

Call and Parameters

The call is made via the header Fr.h specifying the controller index Fr_CtrlIdx, which uniquely identifies the target FlexRay CC in the context of the FlexRay driver [SWS_Fr_00011]. Beyond this, no input and output parameters exist.

Return Values and Error Handling

The function returns a status of type Std_ReturnType [SWS_Fr_00011]:

• E_OK: The API call completed successfully [SWS_Fr_00011].
• E_NOT_OK: The API call was aborted due to errors [SWS_Fr_00011].

Concurrency and Limitations

Regarding concurrency behavior, Fr_AbortCommunication is specified as non-reentrant for the same communication controller (Non Reentrant for the same device) [SWS_Fr_00011]. Parallel calls for the same controller instance must be avoided by the caller.

Usage and Semantics

The function Fr_SendWUP serves to cause a wakeup procedure on the FlexRay bus by issuing the CHI command WAKEUP to the communication controller [SWS_Fr_00009]. The index of the target controller in the driver context is passed via parameter Fr_CtrlIdx [SWS_Fr_00009]. The call takes place asynchronously; the interface initiates the command, while the transmission of the wakeup pattern is subsequently performed on the hardware side [SWS_Fr_00009]. The declaration is available via Fr.h and the service has service ID 0x06 [SWS_Fr_00009].

Error Handling and Return Values

The function returns a status value of type Std_ReturnType [SWS_Fr_00009]:

• E_OK: The API call was executed successfully and the CHI command was issued [SWS_Fr_00009].
• E_NOT_OK: The API call was aborted due to occurred errors [SWS_Fr_00009].

Concurrency and Limitations

The function is specified as non-reentrant for the same device (Non Reentrant for the same device) [SWS_Fr_00009]. Interpretation: This is likely to mean that higher-level modules must synchronize concurrent calls for the same controller instance, whereas calls for different controller instances may be executed concurrently. Question Q-0e3b4e70a0755877 (open) Neither input/output nor pure output parameters are defined [SWS_Fr_00009].

The function Fr_TransmitTxLPdu serves to transmit payload data over the FlexRay network [SWS_Fr_00092]. It processes the transmission request with asynchronous semantics and maps the LSdu to be transmitted to the FlexRay frame identified by Fr_LPduIdx [SWS_Fr_00092].

Usage and Parameters

The call is made via the header file Fr.h (service ID 0x0b) specifying the controller index Fr_CtrlIdx for the FlexRay Communication Controller and the unique frame index Fr_LPduIdx [SWS_Fr_00092]. The pointer Fr_LSduPtr is used to pass the transmit LSdu provided in the buffer, whose data length in bytes is specified via Fr_LSduLength [SWS_Fr_00092]. Via the output parameter Fr_SlotAssignmentPtr, the caller can query the actual transmission cycle, the slot ID, and the FlexRay channel; if this information is not required, a NULL_PTR can be passed for this purpose [SWS_Fr_00092].

Return Values and Error Handling

The function acknowledges the call with the return type Std_ReturnType: The return value E_OK confirms the successful completion of the API call, while E_NOT_OK signals an abortion due to errors [SWS_Fr_00092]. Specific DET or DEM notifications are not contained in the specification data.

Concurrency

Regarding concurrency, Fr_TransmitTxLPdu is specified as non-reentrant for the same device (Non Reentrant for the same device) [SWS_Fr_00092]. Parallel transmission calls for the same FlexRay controller are therefore not permitted.

Usage and Semantics

The synchronous function Fr_CancelTxLPdu cancels the already pending transmission of an L-PDU that is located in a physical transmit resource of the controller (e.g., a transmit buffer) [SWS_Fr_00610]. The function is declared in the header Fr.h and has the service ID 0x2d [SWS_Fr_00610].

To identify the transmission to be cancelled, the interface expects two parameters [SWS_Fr_00610]:

• Fr_CtrlIdx: Index of the FlexRay Communication Controller within the context of the FlexRay driver [SWS_Fr_00610].
• Fr_LPduIdx: Unique index for identifying the respective FlexRay frame [SWS_Fr_00610].

Return Values and Error Handling

The function call returns a status value of type Std_ReturnType [SWS_Fr_00610]:

• E_OK: The API call completed successfully [SWS_Fr_00610].
• E_NOT_OK: The call was cancelled due to errors [SWS_Fr_00610].

Specific error codes, DET or DEM entries are not documented for this function; if an error occurs, the function signals it exclusively via the return value E_NOT_OK [SWS_Fr_00610].

Concurrency and Limitations

With regard to concurrency behavior, Fr_CancelTxLPdu is specified as non-reentrant for the same device (Non Reentrant for the same device) [SWS_Fr_00610]. This presumably means that parallel calls for the same controller instance must be synchronized at caller level. Question Q-ec480944eec04076 (open) Further input or output parameters are not present [SWS_Fr_00610].

The synchronous function Fr_ReceiveRxLPdu serves to receive payload data from the FlexRay network and is available via the header Fr.h [SWS_Fr_00093].

Parameters and usage

Via the input parameters Fr_CtrlIdx and Fr_LPduIdx, the respective communication controller of the FlexRay driver and the FlexRay frame to be received are uniquely addressed [SWS_Fr_00093]. The payload and status data are passed to the caller via several pointers:

• Fr_LSduPtr: Pointer to the buffer in which the received L-SDU is to be stored.
• Fr_LPduStatusPtr: Pointer to the memory location for the reception status of the L-PDU.
• Fr_LSduLengthPtr: Memory location for the length of the received L-SDU in bytes, corresponding to the number of bytes copied into Fr_LSduPtr.
• Fr_SlotAssignmentPtr: Memory location for cycle, slot ID, and channel of the frame. Passing a NULL_PTR for this signals that the caller does not require this assignment information.

Concurrency and Error Handling

The interface is executed synchronously, but is not reentrant for the same device [SWS_Fr_00093]. A successful reception process is acknowledged with E_OK, whereas if errors occur, the call is aborted and E_NOT_OK is returned [SWS_Fr_00093]. Specific DET or DEM error codes are not indicated in the function's specification data.

The synchronous interface Fr_CheckTxLPduStatus (service ID 0x0d) serves, according to [SWS_Fr_00094], to check the current transmission status of an L-SDU or a FlexRay frame in the FlexRay driver. It is provided via the header Fr.h.

As input parameters, the function requires the index of the FlexRay communication controller (Fr_CtrlIdx) as well as the index Fr_LPduIdx, which uniquely identifies the FlexRay frame to be checked in the driver [SWS_Fr_00094]. The determined transmission status of the LPdu is written back to the passed memory address via the output parameter Fr_TxLPduStatusPtr [SWS_Fr_00094].

In addition, the output parameter Fr_SlotAssignmentPtr allows determining the slot assignment: It points to a memory location where the actual cycle, the slot ID, and the channel of the addressed frame are stored [SWS_Fr_00094]. If the caller does not require this assignment information, passing a NULL_PTR signals that these data do not need to be provided [SWS_Fr_00094].

The interface is to be executed synchronously and is specified as non-reentrant for the same device (Non Reentrant for the same device) [SWS_Fr_00094]. Upon successful completion, the call returns the return value E_OK; in the event of errors, the function aborts and returns E_NOT_OK [SWS_Fr_00094].

Usage and Semantics

According to [SWS_Fr_00107], the synchronous function Fr_PrepareLPdu serves to prepare an L-PDU (Prepares a LPdu) and is provided via the header Fr.h. As input parameters, the service expects the controller index Fr_CtrlIdx for addressing the FlexRay Communication Controller (CC) in the driver context as well as Fr_LPduIdx for uniquely identifying the associated FlexRay frame [SWS_Fr_00107]. Interpretation: The call is likely to initialize or arm hardware-specific buffer structures for the subsequent transmission or reception process of the frame. Question Q-c4375099d73dbea2 (open)

Concurrency and Limitations

Regarding concurrency behavior, Fr_PrepareLPdu is specified as non-reentrant for the same hardware device (Non Reentrant for the same device) [SWS_Fr_00107]. A parallel or interrupting call for the same controller index Fr_CtrlIdx must therefore be strictly avoided by the caller.

Return Values and Error Handling

The function has the service ID 0x1f and reports its status via the return type Std_ReturnType [SWS_Fr_00107]:

• E_OK: The API call ended successfully [SWS_Fr_00107].
• E_NOT_OK: The API call was aborted prematurely due to errors that occurred [SWS_Fr_00107]. Specific DET or DEM error codes are not defined in the present specification excerpt.

Usage and Parameters

The synchronous function Fr_ReconfigLPdu enables the dynamic reconfiguration of a FlexRay LPDU at runtime [SWS_Fr_00524]. Provided via the header Fr.h, the call addresses the respective FlexRay controller via Fr_CtrlIdx and the unique identifier of the frame via Fr_LPduIdx AUTOSAR_SWS_FlexRayDriver p. 65.

The following target parameters are passed during reconfiguration [SWS_Fr_00524]:

• Fr_FrameId and Fr_ChnlIdx: Definition of the new frame ID and the communication channel.
• Fr_CycleRepetition and Fr_CycleOffset: Configuration of cycle filtering for the LPDU.
• Fr_PayloadLength and Fr_HeaderCRC: Payload length in bytes as well as the associated header CRC of the frame.

Concurrency and return values

The service is non-reentrant for the same controller (Non Reentrant for the same device) [SWS_Fr_00524]. For calls for different FlexRay controller instances, however, reentrancy is likely given (interpretation). Question Q-85908ef4796c80c7 (open) Upon successful reconfiguration, the call returns E_OK; if reconfiguration fails due to errors, E_NOT_OK is returned AUTOSAR_SWS_FlexRayDriver p. 65.

use

The synchronous driver function Fr_DisableLPdu is used to disable the hardware resource of a FlexRay LPdu for transmission or reception ([SWS_Fr_00539]). The interface is provided via the header file Fr.h and is assigned to the service ID 0x26 ([SWS_Fr_00539]).

Two mandatory parameters must be passed for the function call ([SWS_Fr_00539]):

• Fr_CtrlIdx: The index of the FlexRay communication controller within the driver context.
• Fr_LPduIdx: The unique index identifying the respective FlexRay frame or LPdu.

As a return value, the function returns the status Std_ReturnType ([SWS_Fr_00539]). The value E_OK signals a successfully completed call, whereas E_NOT_OK is returned if the call was aborted due to an error.

Error handling

In the present specification, no specific error codes and no notifications to DET or DEM are defined for this service; the error behavior manifests itself directly in the return value E_NOT_OK ([SWS_Fr_00539]).

Concurrency and Limitations

Regarding reentrancy, Fr_DisableLPdu is classified as non-reentrant for the same device (Non Reentrant for the same device) ([SWS_Fr_00539]). Callers must therefore ensure that concurrent calls for the same controller are synchronized.

The synchronous function Fr_CancelAbsoluteTimer serves to orderly halt an active absolute timer on a FlexRay Communication Controller ([SWS_Fr_00095]). It is provided via the header file Fr.h and has the service ID 0x13 ([SWS_Fr_00095]).

Parameters and Return Value

• Fr_CtrlIdx: Passes the index of the respective FlexRay Communication Controller in the context of the FlexRay driver ([SWS_Fr_00095]).
• Fr_AbsTimerIdx: Determines the index of the absolute timer to be stopped in the context of the selected FlexRay controller ([SWS_Fr_00095]).
• Return value: Provides via the type Std_ReturnType the status E_OK upon successful execution or E_NOT_OK if the call was aborted due to errors ([SWS_Fr_00095]).

Concurrency and Limitations

Regarding concurrency, the interface is defined as non-reentrant for the same device ("Non Reentrant for the same device") ([SWS_Fr_00095]). Calling layers must ensure that no competing or preemptive accesses occur for the same controller. Interpretation: For different controllers, however, execution is presumably permitted as reentrant. Question Q-01203b0b28193021 (open)

The synchronous function Fr_EnableAbsoluteTimerIRQ serves to enable the interrupt line of an absolute timer within a FlexRay Communication Controller [SWS_Fr_00034]. The service is provided via the header file Fr.h and has the Service ID 0x15 [SWS_Fr_00034].

When called, the interface expects two input parameters [SWS_Fr_00034]:

• Fr_CtrlIdx: Index of the FlexRay Communication Controller within the context of the FlexRay driver [SWS_Fr_00034].
• Fr_AbsTimerIdx: Index of the absolute timer within the context of the addressed FlexRay controller [SWS_Fr_00034].

The return value of type Std_ReturnType signals the result of the execution [SWS_Fr_00034]:

• E_OK: The API call completed successfully [SWS_Fr_00034].
• E_NOT_OK: The function call was aborted due to errors [SWS_Fr_00034].

Regarding concurrency, the function is specified as non-reentrant for the same device (“Non Reentrant for the same device”) [SWS_Fr_00034]. This requires that concurrent calls for the same controller instance must strictly be avoided; presumably, however, a parallel call for different controller instances is permissible. Question Q-d7e594a84357e129 (open) Specific error codes for development or production errors (DET/DEM) are not listed in the functional description; errors that occur immediately result in the return of E_NOT_OK [SWS_Fr_00034].

The synchronous function Fr_AckAbsoluteTimerIRQ belongs to the FlexRay driver module (Fr) in the AUTOSAR Classic Platform and serves to reset the interrupt condition of an absolute timer [SWS_Fr_00036]. The declaration of the interface is provided via the header file Fr.h and is assigned to the hexadecimal service ID 0x17 [SWS_Fr_00036].

To uniquely address the timer, the function expects two input parameters of type uint8, while no input/output or pure output parameters are present [SWS_Fr_00036]:

• Fr_CtrlIdx: Passes the index of the FlexRay Communication Controller (CC) within the context of the FlexRay driver [SWS_Fr_00036].
• Fr_AbsTimerIdx: Designates the index of the absolute timer within the context of the respective FlexRay Communication Controller [SWS_Fr_00036].

The result of the function execution is reported back via the status value of type Std_ReturnType. If the call completed successfully, the function returns E_OK [SWS_Fr_00036]. If errors occur during execution, the function call aborts prematurely and returns E_NOT_OK instead [SWS_Fr_00036].

Regarding concurrency behavior, the service is classified as non-reentrant for the same device (Non Reentrant for the same device) [SWS_Fr_00036]. Calls for the same controller instance must therefore take place synchronously and must not be executed concurrently in an overlapping manner [SWS_Fr_00036].

In the FlexRay driver, the synchronous function Fr_DisableAbsoluteTimerIRQ serves to specifically disable the interrupt line of an absolute timer [SWS_Fr_00035]. As input parameters, the interface expects the controller index Fr_CtrlIdx to address the respective FlexRay communication controller (CC) in the driver context, as well as Fr_AbsTimerIdx to identify the absolute timer within this controller [SWS_Fr_00035]. The declaration of the function is provided via the header file Fr.h [SWS_Fr_00035].

The result of the execution is communicated synchronously to the caller via the return type Std_ReturnType [SWS_Fr_00035]. If the service was able to finish properly and successfully, it returns E_OK [SWS_Fr_00035]. If, however, errors occur during processing, the function aborts the operation and signals this via the return value E_NOT_OK [SWS_Fr_00035]. Concrete development or runtime errors (DET/DEM) are not indicated in the specification element, so that error states must primarily be detected and handled on the basis of the return value [SWS_Fr_00035].

Regarding concurrency, Fr_DisableAbsoluteTimerIRQ is defined as non-reentrant for the same device [SWS_Fr_00035]. Therefore, multiple calls for the same controller index must not occur concurrently and must be synchronized by the caller, whereas parallel access to different controllers is permitted [SWS_Fr_00035].

The synchronous function Fr_ReadCCConfig reads a specific FlexRay protocol configuration parameter of a controller directly from the module configuration of the FlexRay driver [SWS_Fr_00651]. The interface is declared via the header Fr.h and has the service ID 0x2e [SWS_Fr_00651].

Parameters and Return Values

• Fr_CtrlIdx: Determines the index of the affected FlexRay communication controller in the driver context [SWS_Fr_00651].
• Fr_ConfigParamIdx: Identifies the parameter to be read via defined macros of format FR_CIDX_<config_parameter_name> [SWS_Fr_00651].
• Fr_ConfigParamValuePtr: Pointer to the memory address of type uint32 to which the read value is written [SWS_Fr_00651].
• Return value: Returns E_OK upon successful execution or E_NOT_OK in case of error [SWS_Fr_00651].

Concurrency and Error Behavior

The function is designed to be non-reentrant for the same controller (\"Non Reentrant for the same device\") [SWS_Fr_00651]. Concurrent calls for different controller instances are therefore likely permissible. Question Q-b5e4172654514747 (open) Specific DET or DEM errors are not named in the interface definition; error states result in termination with return of E_NOT_OK [SWS_Fr_00651]. The caller presumably has to ensure that Fr_ConfigParamValuePtr points to a valid memory area.

The enumeration type Fr_SlotModeType is part of the interface definition of the FlexRay driver in AUTOSAR Classic and is provided via the header Fr_GeneralTypes.h [SWS_Fr_00506]. The type definition formally refers to the type T_SlotMode from the FlexRay protocol specification, where it is described in the chapter on Protocol Operation Control (POC status) [SWS_Fr_00506].

The enumeration specifies the state of slot processing of the controller using three fixedly defined values [SWS_Fr_00506]:

• FR_SLOTMODE_KEYSLOT (value 0x00): Maps the literal KEYSLOT of the formal type definition T_SlotMode [SWS_Fr_00506].
• FR_SLOTMODE_ALL_PENDING (value 0x01): Maps the literal ALL_PENDING of the formal type definition T_SlotMode [SWS_Fr_00506].
• FR_SLOTMODE_ALL (value 0x02): Maps the literal ALL of the formal type definition T_SlotMode [SWS_Fr_00506].

When used with controllers compliant with the older FlexRay 2.1 Rev A standard, a differing naming must be taken into account: Instead of the literal KEYSLOT, the literal SINGLESLOT occurs here [SWS_Fr_00506]. Interpretation: At the driver and software level, the type presumably serves to determine whether the FlexRay controller has currently enabled only key slots (Key Slots) or all slots for transmission, or whether a corresponding transition is pending. Question Q-f926c41c8a5d3380 (open)

use

The enumeration type Fr_ErrorModeType maps the error modes of the FlexRay Protocol Operation Control (POC) and is provided via the header file Fr_GeneralTypes.h [SWS_Fr_00507]. The enumeration defines the states of the error monitoring mechanism of the communication controller and refers to the formal type definition T_ErrorMode in the FlexRay POC status [SWS_Fr_00507].

The range of values comprises three states according to [SWS_Fr_00507]:

• FR_ERRORMODE_ACTIVE (0x00): Represents the literal ACTIVE of the formal type definition T_ErrorMode and designates the error-free state or normal operation of the communication controller.
• FR_ERRORMODE_PASSIVE (0x01): Corresponds to the literal PASSIVE of the formal type definition T_ErrorMode, in which errors were registered on the bus and communication may be degraded.
• FR_ERRORMODE_COMM_HALT (0x02): Maps the literal COMM_HALT of the formal type definition T_ErrorMode when bus communication was stopped due to severe error conditions.

Integration and Boundary Conditions

Interpretation: The type is likely to serve primarily as a return value or status parameter in query functions of the FlexRay driver to communicate the state of the controller to higher-level software layers. Question Q-e4d6ae534d1dfa2c (open) Since [SWS_Fr_00507] exclusively specifies the data structure, no standalone error handling via DET or DEM and no direct requirements on reentrancy or concurrency exist at the type level.

The enumeration type Fr_WakeupStatusType is provided via the header file Fr_GeneralTypes.h and maps the wakeup status of the FlexRay driver according to the formal definition T_WakeupStatus from the POC status [SWS_Fr_00508].

Usage and Value Range

The type represents the various states and events during a FlexRay wakeup process and comprises seven specific enumeration values [SWS_Fr_00508]:

• FR_WAKEUP_UNDEFINED (0x00): Corresponds to the literal UNDEFINED of the formal type definition [SWS_Fr_00508].
• FR_WAKEUP_RECEIVED_HEADER (0x01): Designates the reception of a wakeup header (literal RECEIVED_HEADER) [SWS_Fr_00508].
• FR_WAKEUP_RECEIVED_WUP (0x02): Represents the received wakeup pattern (literal RECEIVED_WUP) [SWS_Fr_00508].
• FR_WAKEUP_COLLISION_HEADER (0x03): Indicates a collision on a received header (literal COLLISION_HEADER) [SWS_Fr_00508].
• FR_WAKEUP_COLLISION_WUP (0x04): Signals a collision during a wakeup pattern (literal COLLISION_WUP) [SWS_Fr_00508].
• FR_WAKEUP_COLLISION_UNKNOWN (0x05): Describes a collision with unknown cause (literal COLLISION_UNKNOWN) [SWS_Fr_00508].
• FR_WAKEUP_TRANSMITTED (0x06): Confirms the successful transmission of the wakeup signal (literal TRANSMITTED) [SWS_Fr_00508].

Interaction and Constraints

Interpretation: The type is likely to serve primarily as a status parameter of driver functions to enable higher-level modules to perform precise diagnostics of the channel and wakeup status. Question Q-48907418bc3729a1 (open) Since the specification defines no specific error codes or concurrency restrictions for the type itself, its use is subject to the call conventions of the respective querying API functions [SWS_Fr_00508].

The enumeration type Fr_StartupStateType is provided according to [SWS_Fr_00509] via the header file Fr_GeneralTypes.h and maps the startup states of the FlexRay protocol controller (POC status) to standardized values. The definition refers to the formal type definition T_StartupState from Chapter 2.2.1.3 of the specification.

The range of values comprises eleven discrete states that represent the progression of the protocol startup:

• FR_STARTUP_UNDEFINED (0x00): Represents an undefined startup state.
• FR_STARTUP_COLDSTART_LISTEN (0x01) to FR_STARTUP_COLDSTART_GAP (0x09): Represent the phases of the coldstart, including listen phase, consistency check, collision resolution, and joining (coldstart join).
• FR_STARTUP_INTEGRATION_LISTEN (0x06), FR_STARTUP_INITIALIZE_SCHEDULE (0x07), and FR_STARTUP_INTEGRATION_CONSISTENCY_CHECK (0x08): Represent integration and initialization steps in the schedule.
• FR_STARTUP_EXTERNAL_STARTUP (0x0A): Represents the externally controlled startup.

Integrating software modules use this type (interpretation: primarily for status polling or monitoring the controller startup). Question Q-7d07faa6c48d4e58 (open) Since Fr_StartupStateType is a pure type definition, no error codes or error messages are triggered directly; however, evaluators must note that values outside the range from 0x00 to 0x0A are unspecified.

The data type Fr_POCStatusType is specified as a data structure and is provided via the header file Fr_GeneralTypes.h [SWS_Fr_00510]. The formal definition refers to the description of the type T_POCStatus in Chapter 2.2.1.3 (POC status) of the FlexRay protocol specification [SWS_Fr_00510].

Usage and Structure Layout

The structure aggregates the current operational and protocol state of the FlexRay Protocol Operation Control (POC) [SWS_Fr_00510]. It is composed of the following elements:

• State (type Fr_POCStateType) and StartupState (type Fr_StartupStateType) to specify the current POC state as well as the startup status [SWS_Fr_00510].
• ErrorMode (type Fr_ErrorModeType) and Freeze (type boolean) to designate the error mode and a controller halt [SWS_Fr_00510].
• SlotMode (type Fr_SlotModeType) and WakeupStatus (type Fr_WakeupStatusType) for the slot mode and wakeup status [SWS_Fr_00510].
• CHIHaltRequest, CHIReadyRequest, and ColdstartNoise (each boolean) to signal host interface requests and line noise during the coldstart [SWS_Fr_00510].

Concurrency and Integration

Interpretation: Since Fr_POCStatusType is a pure data structure without its own functional logic, it likely functions primarily as an output parameter in status queries of the FlexRay hardware. Question Q-960f2475ff1068fc (open) If multiple tasks or software layers access instances of this structure, callers must independently ensure appropriate synchronization to guarantee consistent reading of the related substates [SWS_Fr_00510].

In the AUTOSAR Classic Platform, the enumeration type Fr_TxLPduStatusType serves to determine whether a FlexRay LPdu (Link Layer Protocol Data Unit) was successfully transmitted or not [SWS_Fr_00511]. The type definition is provided for software modules via the header file Fr_GeneralTypes.h [SWS_Fr_00511].

The range of values of the enumeration comprises three unique status states for transmission operations [SWS_Fr_00511]:

• FR_TRANSMITTED (0x00): The LPdu was successfully transmitted over the bus [SWS_Fr_00511].
• FR_TRANSMITTED_CONFLICT (0x01): A conflict occurred during the transmission [SWS_Fr_00511].
• FR_NOT_TRANSMITTED (0x02): The LPdu was not transmitted [SWS_Fr_00511].

With regard to the interaction and the call context, this status value is typically expected to be used by upper layers to query the transmission buffer state in the FlexRay driver (interpretation). Question Q-347a88512db1f006 (open) Specific error codes, error handling routines, as well as DET or DEM reports are not provided for this data type in the specifications, as it is a pure type declaration [SWS_Fr_00511].

The enumeration type Fr_RxLPduStatusType is part of the AUTOSAR Classic module Fr and is provided via the header file Fr_GeneralTypes.h [SWS_Fr_00512]. It serves to determine whether an L-PDU (FlexRay Link Layer PDU) has been received or not [SWS_Fr_00512].

The type defines three discrete status values to evaluate the reception status [SWS_Fr_00512]:

• FR_RECEIVED (0x00): The L-PDU was successfully received [SWS_Fr_00512].
• FR_NOT_RECEIVED (0x01): The L-PDU was not received [SWS_Fr_00512].
• FR_RECEIVED_MORE_DATA_AVAILABLE (0x02): The L-PDU was received and further instances of this L-PDU are available, as occurs when using receive FIFOs [SWS_Fr_00512].

In receive operation via buffer structures, the type not only distinguishes the presence of received data, but additionally indicates the presence of further instances in FIFO operation [SWS_Fr_00512]. This is likely intended to signal to the caller that further data can be retrieved immediately from the FIFO after reading out the current instance [SWS_Fr_00512]. Question Q-0ab7cac72ff7f549 (open)

The structure Fr_SlotAssignmentType serves to store assignment information of a FlexRay frame to a communication cycle and a slot ID [SWS_Fr_91002]. It is defined in the header Fr_GeneralTypes.h and combines all addressing parameters required for transmitting or receiving a frame on the FlexRay channel [SWS_Fr_91002].

The structure comprises the following elements [SWS_Fr_91002]:

• Cycle (type uint8): Indicates the cycle in which the FlexRay frame is transmitted or received [SWS_Fr_91002].
• SlotId (type uint16): Designates the unique slot ID of the frame within the FlexRay communication schedule [SWS_Fr_91002].
• channelId (type Fr_ChannelType): Specifies the FlexRay channel via which transmission or reception takes place [SWS_Fr_91002].

Since Fr_SlotAssignmentType represents a pure data structure, it has no execution semantics of its own such as synchronicity or reentrancy and does not trigger DET or DEM error reports itself [SWS_Fr_91002]. The consistency of the contained values for cycle, slot, and channel is likely within the responsibility of the utilizing driver functions (interpretation). Question Q-77f88375e544e298 (open)