Scribd
Upload
21 views

XCP Module User-Guide

Uploaded by

mostafamahmoud.cse
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
21 views

XCP Module User-Guide

Uploaded by

mostafamahmoud.cse
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

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.

You might also like