Scribd
Upload
18 views6 pages

Xcp Module Integration Guide

Uploaded by

mostafamahmoud.cse
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
18 views6 pages

Xcp Module Integration Guide

Uploaded by

mostafamahmoud.cse
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Xcp Module User-Guide

The Xcp module require interfaces from several other AUTOSAR modules, and provides some interfaces also. In this
confluence we’ll list these interfaces and how to use them for anyone who wishes to integrate this module in any stack.

First let’s take a general look at this main function. Basically, it is used as a stub for testing the Xcp functionality. The
Xcp module is a layer built on top of the transport layer. Our module supports CAN and Ethernet communication
protocols. However, we weren’t provided any communication stack; so we couldn’t test the module on CAN protocol.
So, in order to be able to test this module, we need a workaround. So, we used socket communication but we
encapsulated in CAN interfaces. In other words, the Xcp module only sees CanIf interfaces (transmit & receive), but
these interfaces are really implemented in sockets; and the maximum data length of any used packet is 8 bytes. We’ll
see everything in details in the following sections, as we describe every function in this figure below.
1) Xcp Interface:
- As we know every AUTOSAR module needs a
configuration file to be linked with the static
code.
- “Xcp.h” & “Xcp.c” are the static code.

- “XcpCfg.h” “XcpCfg.c” are the configuration


code.

- To use the Xcp module, we need to:


1- provide Xcp_Configuration in “XcpCfg.c” as
shown in the figure here.
2- extern this Xcp_Configuration to the “main.c”.
3- call Xcp_Init() and give it a pointer to this
struct as parameter.

NB: The details on how to provide the


Xcp_Configuration will be explained in a
separate confluence to freely explain the
mechanisms of the XCP protocol.
2) Os Interface:
- As specified by AUTOSAR, the Xcp module (being a CDD) interfaces directly with OS (i.e. doesn’t interface with Rte).

- To be more specific, the Xcp module needs exactly two interfaces from the OS.

- To make our module easy to integrate, we referred to the OS SWS to get the exact APIs provided by the AUTOSAR OS.
Then, we implemented these functions by ourselves in “Os.h” & “Os.c”.

1. Counter:

- The Xcp module needs a counter that increments every 1ms, it’s called Xcp_counter.

- According to the OS SWS, these three APIs are provided by the OS.

- We chose a random counterID.

2. Scheduled functions:

- The main functionality of the Xcp


module is that it provides readings
of internal variables every certain
periods of time. So, these
functions are extremely critical to
the module.

- We invented a function called create_timer(). We use it to call our periodic functions every certain amounts of time.
We use POSIX timers. This function takes 3 parameters:
* period of scheduled function in ms.
* pointer to scheduled function
* pointer to integer value passed to the scheduled
function.

- Basically, we only need two functions to be


scheduled:
* Xcp_Main_Function(): it’s period is specified in “XcpCfg.h”
* Xcp_Main_Function_Channel(): this function is supposed to be called at certain events. These events are provided by
the user. For now, we only use periodic events. So, the user specifies in the configuration struct that he wants this
function to be called every 10 seconds, so we calculate the time in ms by multiplying the timeCycle by the timeUnit.
This function is called by all events, but each event has a specific channel number so this function knows which event
called it. You will see the same function pointer used in create_timer2(), create_timer3(), ...

3) CAN Interface:
- As mentioned in the introduction, the module supports CAN communication protocol. However, we weren’t provided
any communication stack, so we need a workaround. We used sockets to simulate the CAN protocol.

1. Connect:
- Xcp_CanIfConnect() connects to a socket
and returns the socket ID. It’s different
from its CAN counterpart, but we needed
it.

2. Receive:
- We receive packets using sockets, then we pack it in a PduInfoPtr, then we
call CanIfRxIndication() with the new PduInfoPtr; as if the CAN bus received a
pdu and called this function with the received Pdu. So from the point of view
of the Xcp module, it has received a pdu from the CAN bus.

- CanIfRxIndication() calls
Xcp_RxIndication() which is the function
that is handles received packets in the
Xcp module.

- In Xcp module, we have a fifo called


Xcp_FifoRx where we put received packets to be processed
later by the scheduled Main_function().
3. Transmit:
- To transmit any packet from the Xcp module, we
need to put it in a special fifa called Xcp_FifoTx.

- Then, the scheduled Main_function() process this fifo


by calling Xcp_Transmit_Main() that pops the packet-
to-send from the fifo then call TriggerTransmit() and
give this packet.

- TriggerTransmit() then writes this packet to the other


sockets. So, from the point of view of the Xcp module,
the packet is sent by CAN APIs.

- After the transmission completes, TxConfirmation() is


called.

NB:
CanIfRxIndication(), TriggerTransmit(),TxConfirmation() are the APIs specified by the AUTOSAR SWS for CAN.
4) Memory Interface:
- In this interface, given that we weren’t provided
any memory stack, we used POSIX shared
memory, and we accessed addresses directly.

- First, we open a shared memory segment starting


with address 0x6d592000, with size 20 * 4bytes.

- Then, we fill this memory from another process,


we called it “Example1.c”, as we see in the figure here.

- If we wanted to read the variable placed in our memory segment, we simply dereference the pointer holding the
address (i.e. no memory interface).
Ex: here we have the address reserved in ent->XcpOdtEntryAddress. To get the value stored in this address, we cast
this address to a pointer then we dereference it.
NB: This pointer here points to a 4byte variable, but in other functions, it can point to a 1byte variable.

- If we wanted to write to the variable placed in our memory segment, we simply dereference the pointer holding the
address (i.e. no memory interface) and put the value.
Ex: here we have the address reserved in odt->XcpOdtEntry->XcpOdtEntryAddress. To write a value places in
received_Stim_data to this address, we cast this address to a pointer then we dereference it and we put the value.
NB: This pointer here points to a 4byte variable, but in other functions, it can point to a 1byte variable.

Common questions

Powered by AI

Function pointers in the Xcp module's scheduling mechanism allow for dynamic assignment of specific functions to tasks scheduled by create_timer(). By accepting a pointer to the scheduled function as an argument, different tasks can be executed based on varying conditions or configurations, enhancing the module's flexibility in handling a variety of event-driven operations .

The Xcp module is described as a layer built on top of the transport layer because it relies on underlying transport mechanisms like CAN and Ethernet for data transmission. This architectural design indicates that the Xcp module handles higher-level application functionalities, such as data measurement and calibration, while depending on the transport layer for communication logistics, highlighting its role as an intermediary between application and transport functionalities .

The Xcp module supports CAN and Ethernet communication protocols. Due to the absence of a provided communication stack, a workaround was used involving socket communication encapsulated in CAN interfaces to simulate the testing environment .

In the absence of a dedicated memory stack, the Xcp module uses POSIX shared memory for memory operations. It opens a shared memory segment, and memory addresses are accessed directly by dereferencing pointers. Reading and writing to the memory segment is managed by casting memory addresses to pointers and dereferencing them to access the stored values .

Periodic function execution in the Xcp module is achieved using the 'create_timer()' function, which relies on POSIX timers. This function schedules tasks by specifying the execution period, a pointer to the function to be called, and a pointer to an integer passed as an argument to the function. This approach ensures the Xcp_Main_Function() and Xcp_Main_Function_Channel() are executed periodically based on configurations specified in 'XcpCfg.h' .

Xcp_FifoRx is a FIFO structure used to store received CAN messages temporarily until they are processed by the scheduled Main_function(). Xcp_FifoTx, on the other hand, is used for storing outgoing CAN messages, which will later be sent using the TriggerTransmit() function after being processed by Xcp_Transmit_Main(). Both FIFOs play crucial roles in managing the asynchronous nature of CAN message handling in the absence of a direct CAN communication stack .

The function Xcp_Main_Function() is critical for the Xcp module's main functionality, which includes providing internal variable readings at specified intervals. Its execution is controlled by specifying its period in 'XcpCfg.h', which determines how frequently the function is executed to process scheduled tasks and manage received data .

The Xcp module interfaces directly with the operating system (OS) to access two essential APIs: a counter incrementing every 1ms and scheduled functions critical for the module's operation. This direct interaction is necessary because AUTOSAR mandates that the Xcp module, being a Complex Device Driver (CDD), should not interface with the Runtime Environment (RTE).

The Xcp module uses sockets to simulate CAN communication by handling sockets as if they were CAN interfaces. packet reception and transmission are managed through socket connections, and functions like Xcp_CanIfConnect(), CanIfRxIndication(), and TriggerTransmit() replicate CAN communication functions. This approach enables CAN protocol testing without a physical CAN stack but requires additional logic to mimic CAN behavior using socket-based networking .

To initialize and integrate the Xcp module into an AUTOSAR environment, developers need to provide the Xcp_Configuration in 'XcpCfg.c' and extern it to 'main.c'. Subsequently, Xcp_Init() is called with a pointer to this configuration structure as a parameter. Proper setup of configuration files 'Xcp.h' and 'XcpCfg.h', along with the static code 'Xcp.c', ensures the module is operationally ready within the AUTOSAR framework .

You might also like