BSW/
  ├── Il/          # Interaction Layer (il.c, il_def.h)
  ├── Tp/          # Transport Protocol (tpmc.c)
  ├── Xcp/         # XCP Protocol and CAN adaption (xcp_can.c, xcp_can.h, XcpProf.c, _xcp_appl.c)
  ├── Nm/          # PSA Station Manager (Stat_mgr.h)
  └── VStdLib/     # Vector standard library (vstdlib_lib.asm)
Doc/
  └── DeliveryInformation/ # Delivery documentation

1.1.3 - AN-ISC-2-1029_Transceiver_Handlings

 
Transceiver Handling 
Version 1.2 
2007-09-17 
Application Note  AN-ISC-2-1029 
 
 
 
Author(s) Hussain 
Darwish 
Restrictions Restricted 
membership 
Abstract 
This application note describes how to handle the transceiver before or after calling Vector's API. 
 
 
Table of Contents 
 
1.0 
Introduction ......................................................................................................................................................1 
2.0 
Transceiver Handling .......................................................................................................................................2 
2.1 
Initialization....................................................................................................................................................2 
2.2 
Sleep Mode ...................................................................................................................................................2 
2.3 
Wakeup .........................................................................................................................................................2 
3.0 
Special Considerations ....................................................................................................................................2 
3.1 
Possible Deadlock.........................................................................................................................................2 
3.2 
Return Value of the Function CanSleep() .....................................................................................................3 
4.0 
CAN Communication Layer (CCL)...................................................................................................................3 
5.0 
Contacts...........................................................................................................................................................3 
 
 
 
1.0 Introduction 
In communications, transceivers are used to convert the voltage level of the signal to a different signal form such 
as lights, frequency or even different voltage level. the appropriate bus voltage level to communicate through a 
medium. to be more resistant to transient noise, and reduce the Electromagnetic Emission (EME). Transceivers 
also detect collisions in the bus. There are different transceivers for different applications. For instance, the 
automotive industry uses three types of transceivers: 
1.  High Speed Transceivers (ISO 11898-2): the most common type used in the automotive industry. They 
are mostly used in power train buses and can handle baud rates up to 1Mbps. 
2.  Fault-Tolerant Transceivers (ISO 11898-3):  used mostly in slow baud rate buses like body bus and can 
handle baud rates up to 125kbps. The major advantage of this type of transceivers is that they can 
communicate without errors even if one bus line gets disconnected, shorted to ground or battery. Also, 
they can communicate without errors if both bus lines are shorted together. However, they cannot 
communicate if both bus lines are disconnected, shorted to ground or battery. Up to 32 nodes can be 
connected to the fault-tolerant bus. 
 
 
 
Microcon
Tx
Transc
Rx
trol
eiver
STB
CANL
ler 
EN
CAN
 
H
 
Figure 1: High-Speed and Fault-Tolerant Transceiver Wiring 
 
Copyright © 2007 - Vector Informatik GmbH 
1 
Contact Information:   www.vector-informatik.com   or +49 (0)711 80670-0 

---

  
Transceiver 
Handling 
 
 
 
 
 
 
When using Vector’s embedded software, the user has to switch the transceiver to a certain mode before or after 
calling specific functions. In the following sections, the transceiver handling is explained. 
 
2.0 Transceiver Handling 
Essentially, the transceiver shall be handled in three situations: 
1.  During initialization (after a reset) 
2.  After putting the CAN cell into sleep mode 
3.  During a wakeup 
 
2.1 Initialization 
The transceiver must be switched into Normal mode before calling the CAN driver initialization function 
CanInitPowerOn(). Some CAN cells needs to monitor 11 consecutive recessive bits to initialize (or enter 
configuration mode). If the CAN transceiver is not in Normal mode, it may assert the Rx line to a dominant state. 
Consequently, if the transceiver is not in Normal mode and the function CanInitPowerOn() (or CanInit()) is 
called, the function may not finish executing as it is waiting for 11 recessive bits to synchronize the CAN cell to the 
bus. Some CAN cells do not need to monitor any recessive bit to initialize and thus the transceiver do not have to 
be in Normal mode before calling the CAN driver initialization function. However, for consistency and portability 
reasons, we strongly recommend that the transceiver is in Normal mode before calling the initialization function. 
2.2 Sleep 
Mode 
When using the sleep mode feature of the CAN cell, make sure to switch the transceiver into low-power or standby 
mode AFTER switching the CAN cell into sleep mode. In other words, the transceiver should be switched into low-
power or standby mode only after calling the function CanSleep(). If the function CanSleep() returns kCanFailed, 
the application must not put the transceiver into low-power or standby mode. 
2.3 Wakeup 
When the application wants to wake up the CAN cell to transmit a message, he/she shall switch the transceiver 
into Normal mode before waking the CAN cell (or calling the function CanWakeUp()), Some CAN cells cannot 
wakeup properly until they monitor 11 consecutive recessive bits in the bus. If the transceiver is not in Normal 
state, it may assert the Rx line to dominant state (due to a received wakeup signal from the CAN bus). 
Consequently, the CanWakeUp() function may not finish executing as it is waiting for 11 recessive bits to synchronize the CAN 
cell to the bus. 
 
3.0 Special Considerations 
3.1 Possible 
Deadlock 
 
Make sure that the CAN cell is in sleep mode when the transceiver is in sleep or standby mode. If the CAN cell is 
not in sleep mode and the transceiver is in sleep or standby mode, activities from the bus will never be detected. 
This is because the CAN cell wakes up from the sleep mode when it detects a dominant bit on the Rx pin. When 
the transceiver is in sleep or standby mode, it will try to wake up the CAN cell by signaling a dominant level on the 
Rx pin. From there, the microcontroller will send a wakeup event to the application and the application will switch 
the transceiver into Normal mode. 
 
On the other hand, if the transceiver is in sleep or standby mode while the CAN cell is in Normal operation mode, 
the microcontroller will never detect a wakeup event as the CAN cell is not in sleep mode. Since the wakeup event 
 
Application Note  AN-ISC-2-1029 
 
2 
 

---

  
Transceiver 
Handling 
 
 
 
 
 
is not detected nor passed to the application (via the function ApplCanWakeUp()), the application may never be 
able to switch the transceiver into Normal mode. Consequently, the application will not be able to transmit nor 
receive CAN messages on the bus and may stick in a deadlock situation. 
3.2  Return Value of the Function CanSleep() 
 
As a result of the possible deadlock mentioned in the previous section, the application must check the return value 
of the function CanSleep() when calling it. If CanSleep() returns kCanOk, the application can put the 
transceiver into sleep or standby mode. If CanSleep() returns kCanFailed, the state of the CAN cell might be 
unknown and thus the application must not put the transceiver into sleep or standby mode. In this case, the CAN 
cell might be in sleep or normal operation mode depending on the hardware. What to be done if CanSleep() 
returns kCanFailed is OEM specific. 
 
Pseudocode example: 
 
if(CanSleep() == kCanOk) 
{ 
    DeactivateTransceiver(); /* Application function to put the 
                                transceiver into standby or  
                                sleep mode */ 
} 
 
4.0  CAN Communication Layer (CCL) 
 
To make the implementation more consistent, Vector offers a layer called ‘Communication Control Layer (CCL)’ 
that takes care of transceiver handling (including initialization, sleep, wakeup, and power-off). In addition, this layer 
controls all other Vector’s software layers initializations and tasks. In other words, CCL is an abstraction layer that 
provides a more consistent interface to the application. 
 
For more information on the CCL layer, please visit our website or contact us. 
 
 
 
 
5.0 Contacts 
 
 
 
 
Vector Informatik GmbH 
Vector CANtech, Inc. 
VecScan AB 
Ingersheimer Straße 24 
39500 Orchard Hill Pl., Ste 550 
Lindholmspiren 5 
70499 Stuttgart 
Novi, MI  48375 
402 78 Göteborg  
Germany 
USA 
Sweden 
Tel.: +49 711-80670-0 
Tel:  +1-248-449-9290 
Tel:  +46 (0)31 764 76 00 
Fax: +49 711-80670-111 
Fax: +1-248-449-9704 
Fax: +46 (0)31 764 76 19  
Email: info@vector-informatik.de 
Email: info@vector-cantech.com 
Email: info@vecscan.com 
 
 
Application Note  AN-ISC-2-1029 
 
3 
 

---

  
Transceiver 
Handling 
 
 
 
 
 
Vector France SAS 
Vector Japan Co. Ltd. 
 
168 Boulevard Camélinat 
Seafort Square Center Bld. 18F 
92240 Malakoff  
2-3-12, Higashi-shinagawa, 
France 
Shinagawa-ku 
Tel:  +33 (0)1 42 31 40 00 
J-140-0002 Tokyo 
Fax: +33 (0)1 42 31 40 09 
Tel.: +81 3 5769 6970    
Email: information@vector-france.fr 
Fax: +81 3 5769 6975 
 
Email: info@vector-japan.co.jp 
 
 
Application Note  AN-ISC-2-1029 
 
4 
 

---

1.1.6 - AN-ISC-2-1035_Start_Stop_Periodic_Transmission_ILs

 
Start Stop Periodic Transmission with IL 
Version 1.3 
2007-08-14  
Application Note AN-ISC-2-1035 
 
 
 
Author(s) Gunnar 
Meiss 
Restrictions Restricted 
membership 
Abstract 
Start and stop a periodical transmission of the Interaction Layer. 
 
 
Table of Contents 
 
 
1.0 
How to start and stop periodic transmission....................................................................................................1 
1.1 
Manufacturer, Hardware platform, derivative................................................................................................1 
1.2 
Problem Description ......................................................................................................................................1 
1.3 
Problem Solution ...........................................................................................................................................1 
1.3.1 
Additional Configuration of the Interaction Layer in CANgen .....................................................................2 
1.3.2 
Configuration of the Interaction Layer in GENy ..........................................................................................3 
1.3.3 
Additional Functions Provided by the Interaction Layer Kernel..................................................................3 
2.0 
Contacts...........................................................................................................................................................5 
 
 
 
1.0  How to start and stop periodic transmission  
1.1  Manufacturer, Hardware platform, derivative 
There are no dependencies between manufacturer, hardware platform and derivative according to this problem. 
1.2 Problem 
Description 
After the transmission path of the IL was started ( IlTxStart() ) the transmission of cyclic message takes place. 
Nothing further is needed to be done to keep the transmission running. The cycle time must be pre-configured in 
the network database at compile time. Some applications need to stop and restart the periodic transmission for 
individual messages. 
1.3 Problem 
Solution 
The periodical transmission can be stopped and restarted by the application optionally. Therefore the Interaction 
Layer provides some additional service functions. The function IlStopCycle(<IlMessageHandle>) stops the periodic 
transmission of a message, the function IlStartCycle(<IlMessageHandle>) restarts the periodic transmission. 
Each call of the function IlTxStart() starts the cyclic transmission. In some cases it might be necessary to avoid the 
cyclic transmission after IlTxStart(). Therefore it is possible to call the function IlStopCycle(<IlMessageHandle>) 
within the callback function ApplIlTxStart(). This disables the cyclic transmission of a message immediately after 
IlTxStart(). In this case the cyclic transmission will not be started for this message.  
 
Caution 
This API shall never be performed on Messages containing multiplexed signals. 
 
 
 1  
Copyright © 2007 - Vector Informatik GmbH 
Contact Information:   www.vector-informatik.com   or ++49-711-80 670-0 
 

---

 
 
Start Stop Periodic Transmission with IL 
 
 
 
 
 
 
 
1.3.1  Additional Configuration of the Interaction Layer in CANgen 
 
Figure 1 - Configuration of the Interaction Layer in the Generation Tool 
 
Figure 1 shows a screen shot of the configuration tool CANgen. Within the tab IL options the Interaction Layer 
could be configured. The relevant option on this tab is shown in the table below. 
Parameter 
Value 
Meaning 
Reference 
Use start/stop  On/Off 
This option is necessary if periodic transmission should 
 
of periodic 
be stopped and restarted during runtime. 
messages 
Table 1 – Il options tab 
 
2 
Application Note AN-ISC-2-1035 
 
 

---

 
 
Start Stop Periodic Transmission with IL 
 
 
 
 
 
 
1.3.2  Configuration of the Interaction Layer in GENy 
 
Figure 2 – Start/Stop API in GENy 
 
Figure 2 shows a screen shot of the configuration tool GENy. On the configuration view of Il Vector the Interaction 
Layer could be configured. The Start/Stop API is the relevant option you have to activate if periodic transmission 
should be stopped and restarted during runtime. 
1.3.3  Additional Functions Provided by the Interaction Layer Kernel 
Name: 
IlStartCycle 
Standard 
void IlStartCycle (IlTransmitHandle ilTxHnd); 
Prototype: 
Multi Channel 
void IlStartCycle_X(IlTransmitHandle ilTxHnd); 
Prototype: 
with X = 0... Number of CAN channel 
Indexed 
void IlStartCycle (IlTransmitHandle ilTxHnd); 
Prototype: 
Argument(s): 
ilTxHandle 
IL Handle of the messages for with the cyclic transmitted  
  should 
be 
restarted 
 
 
The generated <IlMessageHandle> shall be used: 
In CANgen (ilpar.h): 
  _ILTx<MessageName> 
In GENy (il_par.h): 
  IlTxMsgHnd<MessageName> 
Return: None 
Description: 
This function restarts the periodical transmission of a message and shall be called 
on task level. Due to this that all timing counters are set in the state transition tx start 
the callback function ApplIlTxStart may be used to implement the changed cycle 
time behavior. 
Table 2 – Description of IlStartCycle 
 
Name: 
IlStopCycle 
Standard 
void IlStopCycle (IlTransmitHandle ilTxHnd); 
Prototype: 
 
3 
Application Note AN-ISC-2-1035 
 
 

---

 
 
Start Stop Periodic Transmission with IL 
 
 
 
 
 
 
Multi Channel 
void IlStopCycle_X(IlTransmitHandle ilTxHnd); 
Prototype: 
with X = 0... Number of CAN channel 
Indexed 
void IlStopCycle (IlTransmitHandle ilTxHnd); 
Prototype: 
Argument(s): 
ilTxHandle 
IL Handle of the messages for with the cyclic transmitted  
  should 
be 
stopped 
 
 
The generated <IlMessageHandle> shall used: 
In CANgen (ilpar.h):  
  _ILTx<MessageName> 
 
 
In GENy (il_par.h): 
  IlTxMsgHnd<MessageName> 
Return: None 
Description: 
This function stops the periodical transmission of a message and shall be called on 
task level. 
Table 3 – Description of IlStopCycle 
 
 
4 
Application Note AN-ISC-2-1035 
 
 

---

 
 
Start Stop Periodic Transmission with IL 
 
 
 
 
 
 
2.0 Contacts 
 
 
 
 
Vector Informatik GmbH 
Vector CANtech, Inc. 
VecScan AB 
Ingersheimer Straße 24 
39500 Orchard Hill Pl., Ste 550 
Lindholmspiren 5 
70499 Stuttgart 
Novi, MI  48375 
402 78 Göteborg  
Germany 
USA 
Sweden 
Tel.: +49 711-80670-0 
Tel:  +1-248-449-9290 
Tel:  +46 (0)31 764 76 00 
Fax: +49 711-80670-111 
Fax: +1-248-449-9704 
Fax: +46 (0)31 764 76 19  
Email: info@vector-informatik.de 
Email: info@vector-cantech.com 
Email: info@vecscan.com 
 
Vector France SAS 
Vector Japan Co. Ltd. 
 
168 Boulevard Camélinat 
Seafort Square Center Bld. 18F 
92240 Malakoff  
2-3-12, Higashi-shinagawa, 
France 
Shinagawa-ku 
Tel:  +33 (0)1 42 31 40 00 
J-140-0002 Tokyo 
Fax: +33 (0)1 42 31 40 09 
Tel.: +81 3 5769 6970    
Email: information@vector-france.fr 
Fax: +81 3 5769 6975 
 
Email: info@vector-japan.co.jp 
 
 
 
5 
Application Note AN-ISC-2-1035 
 
 

---

1.1.9 - AN-ISC-2-1052_CANbedded_and_Operating_Systemss

 
CANbedded and Operating Systems 
Version 1.0 
2007-01-18  
Application Note  AN-ISC-2-1052 
 
 
 
Author(s) Hartmut 
Hörner, Patrick Markl 
Restrictions Restricted 
Membership 
Abstract 
The Vector CANbedded software components have some requirements for the run-time 
environment. These requirements are described in this application note.  
 
 
Table of Contents 
 
1.0 
Overview ..........................................................................................................................................................1 
2.0 
General Requirements.....................................................................................................................................1 
3.0 
Interrupt Handling ............................................................................................................................................2 
3.1 
Interrupt Service Routines (ISRs) .................................................................................................................2 
3.2 
Access to interrupt control registers..............................................................................................................2 
4.0 
Data consistency..............................................................................................................................................3 
5.0 
Memory protection and virtual memory management .....................................................................................3 
6.0 
Privilege modes ...............................................................................................................................................4 
7.0 
Operating systems with stringent driver models..............................................................................................4 
8.0 
Startup Time ....................................................................................................................................................5 
9.0 
Contacts...........................................................................................................................................................5 
 
 
 
1.0 Overview 
The Vector CANbedded components have some requirements for the run-time environment. Some of these might 
impact the usage of the operating system elements as well as the real-time design. 
Two run-time environments are explicitly supported by CANbedded: 
•  A system without operating system 
•  An OSEK Operating System (version 2.1r1 onwards) such as Vector osCAN 
 
In the following chapters the requirements are listed and for some cases where no explicitly support exists 
workarounds are described. 
2.0 General Requirements 
Higher layer CANbedded components require an initialization function and one or more cyclic functions. 
CANbedded hardware drivers have an initialization function, ISRs in interrupt driven mode and cyclic functions in 
polling mode. The initialization function must be called before the cyclic function is called for the first time and 
before the first ISR occurs. 
The CANbedded stack requires a shared address space with the application since some functionalities such as 
signal and flag access are implemented by macros. 
There are no requirements for dynamic memory management. All not constant global variables are explicitly 
initialized in the initialization functions. There are no requirements for memory initialization in the start-up code 
unless constant data is located in RAM. 
 1  
Copyright © 2007 - Vector Informatik GmbH 
Contact Information:   www.vector-informatik.com   or ++49-711-80 670-0 

---

 
 
CANbedded and Operating Systems 
 
 
 
 
 
Since the CANbedded components have to interface directly with the communication hardware adequate access 
privileges are required. 
3.0 Interrupt Handling 
3.1  Interrupt Service Routines (ISRs) 
If the CAN Driver is used in an interrupt driven mode one or more ISRs must be installed. 
Two categories of ISRs are supported: 
•  ISR implemented with the related compiler pragma or qualifier. This is used in a system without operating 
system and for OSEK-OS ISRs of category 1. 
•  OSEK-OS ISR category 2. 
 
If an operating system other than OSEK is used the following workaround is possible:  
If OSEK-OS and OSEK-OS category 2 ISR support are selected in the generation tool the ISR has the following C 
syntax: 
 
ISR(CanInterrupt) 
{ 
  … 
} 
 
Supply a header file osek.h with the following macro, to make the ISR available in other modules as a void-void 
function. 
 
#define ISR(x) void x(void) 
 
Example for an operating system which provides a service OSRegisterISR to register an ISR: 
 
OSRegisterISR(CanInterrupt, 10);     /* second parameter is interrupt vector number */ 
 
If the prototype of the ISR required by the OS is not of the kind void x(void) an intermediate function must be used 
to circumvent type conflicts. 
3.2  Access to interrupt control registers 
To achieve its own data consistency and to export such services to the application the CANbedded components 
require access to the interrupt control registers of the communication controller and to interrupt control registers of 
the interrupt controller or the CPU which allow to disable interrupts globally or up to a certain level. 
If it is not desirable or possible that the CANbedded components access the global interrupt directly this 
functionality can be replaced by other mechanisms (“interrupt control by application”, supported in CAN driver RI 
version 1.4 onwards).  
If a resource locking mechanism of the operating system is used it must support nested critical sections.  
 
2 
Application Note  AN-ISC-2-1052 
 

---

 
 
CANbedded and Operating Systems 
 
 
 
 
 
4.0 Data consistency 
For efficiency reasons some services of the CANbedded components are implemented as macros with  
unprotected critical sections. If these macros are used in multiple full-preemptive tasks or in multiple ISRs data 
consistency problems can be caused. One of the following solutions is possible: 
•  Use these services only in non-preemptable tasks 
•  Use these services only in one cooperative task group (OSEK: internal resource concept) 
•  Supply critical section in the application code 
 
Some CANbedded components have specific requirements concerning processing priorities and reentrancy. These 
requirements are described in the technical reference of the individual component. 
 
5.0  Memory protection and virtual memory management 
This chapter is only applicable if the processor and the run-time environment support such mechanisms. 
Since some CANbedded services are implemented as macros which access to global variables the application part 
which uses the CANbedded services and the complete CANbedded stack must reside in one address space.  
In addition all CANbedded tasks and ISRs must be able to access the peripheral address space of the 
communication hardware. 
The following figure shows a possible configuration with three different applications with an own address space. 
Two applications perform application tasks (drawn in green), one application is responsible for the communication 
(drawn in red). 
Application 1
Application 2
Communication application
CANbedded stack
Communication hardware
 
Figure 1 Different applications with own address space 
 
To move data between the applications operating system services are required which have the capability to tunnel 
the address barrier (drawn with blue arrows).. 
 
3 
Application Note  AN-ISC-2-1052 
 

---

 
 
CANbedded and Operating Systems 
 
 
 
 
 
6.0 Privilege modes  
This chapter is only applicable if the processor and the run-time environment support such mechanisms. 
In some architectures different privilege modes such as user and supervisor mode are defined. If a task or ISR is 
running in user mode the access to peripheral hardware and global resources such as interrupt control registers 
may be restricted.  
It must be possible to assign all tasks and ISRs which provide or use CANbedded services a sufficient privilege 
level to allow for: 
•  Access to communication hardware 
•  Access to communication related interrupt control 
•  Access to global interrupt control registers including the capability to execute instructions related to global 
interrupt control registers unless interrupt control by application is used (s. chapter 3.2). 
 
If such a privilege level is not possible for tasks but only for ISRs a cyclic timer ISR can be used to perform all 
required CANbedded cyclic processing. Note that such an ISR must have a lower interrupt level than the ISRs of 
the CANbedded drivers. 
7.0  Operating systems with stringent driver models 
This chapter is only applicable if the run-time environment supports such mechanisms. 
In some operating systems hardware access is only allowed for specific hardware drivers which have to follow a 
predefined implementation model. When a hardware driver is called in such a system the required privileges are 
assigned. To allow the usage of CANbedded a wrapper layer between application and CANbedded is required to 
implement the required driver interface. 
Such a design is illustrated in the figure below, the driver interface is drawn with blue arrows: 
Application 1
Application 2
Wrapper layer
CANbedded stack
 
Figure 2 With Wrapper Layer 
 
4 
Application Note  AN-ISC-2-1052 
 

---

 
 
CANbedded and Operating Systems 
 
 
 
 
 
8.0 Startup Time 
Some Operating systems (especially more sophisticated and larger ones) are running out of RAM, while the 
binaries are stored in non-volatile memories like Flash. This requires that the startup code transfers the OS image 
into RAM after power on reset. Depending on the size of the OS image this can take up to several hundreds of 
milliseconds. As a consequence the initialization of the CANbedded stack occurs after the kernel is loaded 
completely. Often this long startup times do not match the OEMs’ startup requirements. There are two possibilities 
to solve this issue. Either the OEM accepts the longer startup time or the operating system supports a mechanism 
that allows initialization of the CANbedded stack before the kernel is loaded completely. 
If the operating system supports some kind of a runtime environment before the kernel is loaded it could be also 
relevant to have a possibility to hand over the information received during the startup phase via CAN to the fully 
loaded kernel environment. 
9.0 Contacts 
 
 
 
 
Vector Informatik GmbH 
Vector CANtech, Inc. 
VecScan AB 
Ingersheimer Straße 24 
39500 Orchard Hill Pl., Ste 550 
Lindholmspiren 5 
70499 Stuttgart 
Novi, MI  48375 
402 78 Göteborg  
Germany 
USA 
Sweden 
Tel.: +49 711-80670-0 
Tel:  +1-248-449-9290 
Tel:  +46 (0)31 764 76 00 
Fax: +49 711-80670-111 
Fax: +1-248-449-9704 
Fax: +46 (0)31 764 76 19  
Email: info@vector-informatik.de 
Email: info@vector-cantech.com 
Email: info@vecscan.com 
 
Vector France SAS 
Vector Japan Co. Ltd. 
 
168 Boulevard Camélinat 
Seafort Square Center Bld. 18F 
92240 Malakoff  
2-3-12, Higashi-shinagawa, 
France 
Shinagawa-ku 
Tel:  +33 (0)1 42 31 40 00 
J-140-0002 Tokyo 
Fax: +33 (0)1 42 31 40 09 
Tel.: +81 3 5769 6970    
Email: information@vector-france.fr 
Fax: +81 3 5769 6975 
 
Email: info@vector-japan.co.jp 
 
 
 
5 
Application Note  AN-ISC-2-1052 
 

---

1.1.12 - AN-ISC-2-1081_Interrupt_Control_VStdLibs

 
Application Interrupt Control with VStdLib 
Version 1.0 
2008-08-06 
Application Note  AN-ISC-2-1081 
 
 
 
Author(s) Patrick 
Markl 
Restrictions Restricted 
Membership 
Abstract 
This application note explains how the application can control interrupt handling via the 
VStdLib and which constraints apply. 
 
 
Table of Contents 
 
1.0 
Overview ..........................................................................................................................................................1 
1.1 
Introduction....................................................................................................................................................1 
2.0 
Interrupt Control by Application .......................................................................................................................3 
2.1 
Constraints ....................................................................................................................................................3 
2.1.1 
Constraint 1: Nested Calls ..........................................................................................................................3 
2.1.2 
Constraint 2: Recursive Calls when Disabling CAN Interrupts...................................................................3 
2.1.3 
Constraint 3: No Locking when Disabling CAN Interrupts..........................................................................3 
3.0 
Solution ............................................................................................................................................................6 
3.1.1 
Nested Calls................................................................................................................................................6 
3.1.2 
No Locking of Interrupts..............................................................................................................................7 
4.0 
Referenced Documents .................................................................................................................................12 
5.0 
Contacts.........................................................................................................................................................13 
 
 
 
1.0 Overview 
This application note describes how the user can configure the interrupt control options of the VStdLib. Some 
applications provide their own lock/unlock functions, which better fulfill the application’s needs. Because of this the 
VStdLib provides a means which allows the application to use it’s own lock/unlock functions, instead of the 
implementation provided by the VStdLib.  
This application note describes the handling of this use case in more detail. 
1.1 Introduction 
The VStdLib provides functions to lock/unlock interrupts. There are three options to be set in the configuration tool, 
as shown in figure1. The first  option (Default) lets the VStdLib lock global interrupts. Depending on the hardware 
plattform it is also possible to lock interrupts to a certain level. The lock is implemented by the VStdLib itself.  
 
 
Figure 1: Possible configuration options for VStdLib interrupt control 
 1  
Copyright © 2008 - Vector Informatik GmbH 
Contact Information:   www.vector-informatik.com   or ++49-711-80 670-0 

---

 
 
Application Interrupt Control with VStdLib 
 
 
 
 
 
 
The second option (OSEK) is to configure the VStdLib in a way that locking of interrupts is done by means of 
OSEK OS functions. The third and last option (User defined) requires the application to perform the 
locking/unlocking functionality within callback functions. 
This application note focusses mainly on the third option. It describes the way the application has to implement the 
callback functions required by the VStdLib.  
 
 
Figure 2: Configuration of interrupt control by application 
 
Figure 2 shows the VStdLib configuration dialog, if interrupt control by application is configured. The user has to 
enter the names of two functions in the dialog, which will be called by the VStdLib in order to lock/unlock interrupts. 
If the user has specified the callback function names as shown in figure 2, the application must provide the 
implementations of these two two functions. The prototypes are: 
 
void ApplNestedDisable(void); 
void ApplNestedRestore(void); 
 
From now on these two function names will be used within this application note. 
These two functions are called by the VStdLib, in case any Vector component requests a lock for a critical section. 
The user has to make sure that the locking mechanism within these two functions is sufficient to protect data. This 
depends heavily on the architecture of the application. The more priority levels exists, which call Vector functions, 
the more restrictive the lock must be. 
 
Please check the technical references of the other Vector components for restrictions regarding the call 
context of the API functions. 
 
 
 
2 
Application Note  AN-ISC-2-1081 
 

---

 
 
Application Interrupt Control with VStdLib 
 
 
 
 
 
2.0  Interrupt Control by Application 
This configuration option is usually used, if a global lock is not desired by the user or special lock mechanisms are 
used. Once this option is configured, there are two functions to be provided by the application. The user can 
specify the names of these functions in the configuration dialog of the VStdLib. The VStdLib calls these functions 
instead of directly locking/unlocking interrupts. This means, if any Vector component requests an interrupt lock, it is 
finally performed by the application provided functions. 
The first function is called, in order to perform a lock operation. It is expected, that the application function stores 
the current interrupt state(or any other), in order to restore it later. The second function is to restore the previously 
saved lock state.  
The implementation of these two functions is up to the user. The user may lock just certain interrupt sources or set 
a mutex, semaphore or whatever ensures consistent data and fulfills the call context requirements, described in the 
Vector component specific technical references. 
2.1 Constraints 
The usage of Interrupt Control by Application has some constraints, which have to be taken into account. The 
following chapters describe them. 
2.1.1  Constraint 1: Nested Calls 
It is expected that the two callback functions (ApplNestedDisable()/-Restore()) are implemented in a way that 
nested calls are possible. This means if the function ApplNestedDisable() was called by some software component 
it may happen that this function is called again from somewhere else. This has to be taken into account when 
saving and restoring the interrupt state! The implementer of these two function can assume that the number of lock 
and unlock calls is identical and nesting is balanced. 
2.1.2  Constraint 2: Recursive Calls when Disabling CAN Interrupts 
Instead of implementing an own lock mechanism, the user could configure interrupt control by application and call 
the CAN driver’s CanCanInterruptDisable()/-Restore() functions. These two function simply disable CAN interrupts 
for the given CAN channel. These two CAN driver functions protect the access to their state variables by means of 
the VStdLib’s lock mechanism, which would again be implemented by the callbacks provided by the application. 
This would cause an indirect recursion. 
 
Please note that CanCanInterruptDisable()/Restore() shall not be called from 
ApplNestedDisable()/Restore(). This application note does not provide a solution for this use case! 
 
 
2.1.3  Constraint 3: No Locking when Disabling CAN Interrupts 
One could think of letting the application directly modify the interrupt flags of the CAN controller, to overcome the 
recursion, described in the previous chapter. But this would cause the CAN interrupts to be never locked, when 
CanCanInterruptDisable() is called, by any component. The reason is that the application’s interrupt lock code 
would interfere with the code in the CAN driver’s function CanCanInterruptDisable(). The following pseudo code 
shows the way CanCanInterruptDisable() is implemented. It is assumed that ApplNestedDisable()/-Restore() are 
implemented to allow nested calls. 
 
 
3 
Application Note  AN-ISC-2-1081 
 

---

 
 
Application Interrupt Control with VStdLib 
 
 
 
 
 
 
/* CAN Interrupt will be never locked in this example!!! */ 
void CanCanInterruptDisable(CAN_CHANNEL_CANTYPE_ONLY) 
{ 
  ApplNestedDisable(); 
  Lock CAN interrupts 
  ApplNestedRestore(); 
} 
 
void ApplNestedDisable(void) 
{ 
  Save current CAN interrupt state(); 
  Lock CAN Interrupts(); 
} 
 
void ApplNestedRestore(void) 
{ 
  Restore CAN interrupts to previous state(); 
} 
 
Figure 3 shows what happens in this case. The function CanCanInterruptDisable() calls ApplNestedDisable() in 
order to protect an internal counter. This lock function disables the CAN interrupts, afterwards the CAN driver’s 
function locks the CAN interrupts too. The next thing is to call ApplNestedRestore() which again is implemented by 
the application and restores the previous CAN interrupt state – in this case enables the CAN interrupts. Now an 
inconsistency exists. The code which called CanCanInterruptDisable() assumes locked CAN interrupts, but they 
aren’t 
 
 
 
4 
Application Note  AN-ISC-2-1081 
 

---

 
 
Application Interrupt Control with VStdLib 
 
 
 
 
 
sd FailedLock
Component
CAN Driver
Application
CAN Controller
CanCanInterruptDisable
VStdGlobalInterruptDisable
Lock CAN Interrupt
Lock CAN Interrupt
VStdGlobalInterruptRestore
Unlock CAN Interrupt
 
Figure 3: Sequence diagram of CanCanInterruptDisable() 
 
 
 
 
 
5 
Application Note  AN-ISC-2-1081 
 

---

 
 
Application Interrupt Control with VStdLib 
 
 
 
 
 
3.0 Solution 
This chapter proposes a solution and a code examples, to overcome the constraints 1 and 3 described in the 
previous chapters. 
3.1.1 Nested 
Calls 
Solving the first issue – nested calls – is simply done by introducation of a nesting counter. The callbacks 
implemented by the application need to manage this counter. The counter is to be incremented, if the function to 
lock interrupts is called and decremented if the unlock function is called. The application has to take care to 
initialize this counter, before any Vector function is called, in order to ensure a consistent interrupt locking. 
The interrupt state is to be modified only if the counter has the value zero. If the value is greater than zero, the 
counter is just maintained. The following code example shows, how this nested counter could be implemented. 
 
/* Global variable as nesting counter */ 
vuint8 gApplNestingCounter; 
 
/* Must be called before the Vector components are initialized! */ 
void SomeApplicationInitFunction(void) 
{ 
  gApplNestingCounter = (vuint8)0; 
} 
 
void ApplNestedDisable(void) 
{ 
  /* check counter – lock if counter is 0 */ 
  if((vuint8)0 == gApplNestingCounter) 
  {  
    /* Save current state and perform lock  */ 
    ApplicationSpecificSaveStateAndLock(); 
  } 
  /* increment counter – do not disable if nested, because already done */ 
  gApplNestingCounter++; 
} 
 
void ApplNestedRestore(void) 
{ 
  gApplNestingCounter--; 
  if((vuint8)0 == gApplNestingCounter) 
  { 
 
6 
Application Note  AN-ISC-2-1081 
 

---

 
 
Application Interrupt Control with VStdLib 
 
 
 
 
 
    ApplicationSpecificRestoreToPreviousState(); 
  } 
} 
 
3.1.2  No Locking of Interrupts 
Constraint 3 described a situation, in which the CAN interrupts are not locked at all. This is because the application 
implements a lock function, which modifes the CAN interrupt registers with own code. To overcome this issue, a 
global flag needs to be implemented. This global flag tells the application, when to lock or unlock CAN interrupts. 
The flag is set within two additional callback functions to be implemented by the application. The prototypes of the 
additional callbacks are: 
 
void ApplCanAddCanInterruptDisable(CanChannelHandle channel); 
void ApplCanAddCanInterruptRestore(CanChannelHandle channel); 
 
The callback functions are called by the CAN driver from within the functions CanCanInterruptDisable() and 
CanCanInterruptRestore() and have to be enabled by means of the preprocessor define 
C_ENABLE_INTCTRL_ADD_CAN_FCT. This is done, by creating a user config file, which contains this definition. 
More information about these two functions can be found in [1]. 
The sequence diagrams in figure 4 and figure 5 show the lock and unlocking procedure respectively. 
 
 
7 
Application Note  AN-ISC-2-1081 
 

---

 
 
Application Interrupt Control with VStdLib 
 
 
 
 
 
sd InterruptControlByApplication_Lock
Component
CAN Driver
VStdLib
Application
CanCanInterruptDisable
CanNestedGlobalInterruptDisable
ApplDisableFunc
Lock if
Flag
cleared
Lock CAN Interrupts
ApplCanAddCanInterruptDisable
Set
Global
Flag
CanNestedGlobalInterruptRestore
ApplRestoreFunc
Unlock
if Flag
cleared
 
Figure 4: Sequence diagram for locking just CAN interrupts. 
 
 
 
 
8 
Application Note  AN-ISC-2-1081 
 

---

 
 
Application Interrupt Control with VStdLib 
 
 
 
 
 
sd InterruptControlByApplication_UnLock
Component
CAN Driver
VStdLib
Application
CanCanInterruptRestore
VStdGlobalInterruptDisable
ApplDisableFunc
Lock if
Flag
cleared
Restore CAN Interrupts
ApplCanAddCanInterruptRestore
Clear Global Flag
VStdGlobalInterruptRestore
ApplRestoreFunc
Unlock
if Flag
cleared
 
Figure 5: Sequence diagram for unlocking just CAN interrupts 
 
The following code example shows how to implement the handling of the global flag. If the function 
CanCanInterruptDisable() is called, it calls the ApplNestedDisable(), in order to protect a counter. This function 
locks CAN interrupts using own code. When ApplNestedDisable() returns, the CAN driver locks CAN interrupts too. 
Afterwards ApplCanAddCanInterruptDisable() is called. This function is implemented by the application and sets 
the global flag. Before the function CanCanInterruptDisable() returns, it calls ApplNestedRestore(). The application, 
which implements the restore callback function has to check, if the global flag is set. If yes, the CAN interrupts 
must not be unlocked! 
If the function CanCanInterruptRestore() is called, first ApplNestedDisable() is called again. Then the CAN driver 
unlocks the CAN interrupts (if its nesting counter reached the value zero) and calls the function 
ApplCanAddCanInterruptRestore(). Within this function the flag is cleared. If ApplNestedRestore() is called now, 
the flag is not set anymore and the restore of the CAN interrupts is performed. 
 
9 
Application Note  AN-ISC-2-1081 
 

---

 
 
Application Interrupt Control with VStdLib 
 
 
 
 
 
Note that the application needs to implement also a nesting counter, if it uses own code to lock CAN interrupts, in 
order to avoid the issue described by constraint 1. The following code example shows, how to implement the 
nesting counter and the flag. 
 
 
vuint8 gCanLockFlag; 
vuint8 gApplNestingCounter; 
 
void ApplicationInitFunction(void) 
{ 
  /* initialize the flags */ 
  gCanLockFlag = (vuint8)0; 
  gApplNestingCounter = (vuint8)0; 
} 
 
void ApplNestedDisable(void) 
{ 
  if((vuint8)0 == gApplNestingCounter) 
  { 
    if((vuint8)0 == gCanLockFlag) 
    { 
      Save current CAN interrupt state(); 
      Lock CAN Interrupts(); 
    } 
  } 
  gApplNestingCounter++; 
} 
 
void ApplNestedRestore (void) 
{ 
  gApplNestingCounter--; 
  if((vuint8)0 == gApplNestingCounter) 
  { 
    if((vuint8)0 == gCanLockFlag) 
    { 
      Restore CAN interrupts to previous state(); 
    } 
 
10 
Application Note  AN-ISC-2-1081 
 

---

 
 
Application Interrupt Control with VStdLib 
 
 
 
 
 
  } 
} 
 
void ApplCanAddCanInterruptDisable(CanChannelHandle channel) 
{ 
  gCanLockFlag = (vuint8)1; 
} 
 
void ApplCanAddCanInterruptRestore(CanChannelHandle channel) 
{ 
  gCanLockFlag = (vuint8)0; 
} 
 
 
 
11 
Application Note  AN-ISC-2-1081 
 

---

 
 
Application Interrupt Control with VStdLib 
 
 
 
 
 
4.0 Referenced Documents 
The following table contains the referenced documents. 
 
Referenced Documents 
[1] TechnicalReference_CANDriver.pdf 
 
 
 
 
12 
Application Note  AN-ISC-2-1081 
 

---

 
 
Application Interrupt Control with VStdLib 
 
 
 
 
 
5.0 Contacts 
 
 
 
 
Vector Informatik GmbH 
Vector CANtech, Inc. 
VecScan AB 
Ingersheimer Straße 24 
39500 Orchard Hill Pl., Ste 550 
Lindholmspiren 5 
70499 Stuttgart 
Novi, MI  48375 
402 78 Göteborg  
Germany 
USA 
Sweden 
Tel.: +49 711-80670-0 
Tel:  +1-248-449-9290 
Tel:  +46 (0)31 764 76 00 
Fax: +49 711-80670-111 
Fax: +1-248-449-9704 
Fax: +46 (0)31 764 76 19  
Email: info@vector-informatik.de 
Email: info@vector-cantech.com 
Email: info@vecscan.com 
 
Vector France SAS 
Vector Japan Co. Ltd. 
Vector Korea IT Inc. 
168 Boulevard Camélinat 
Seafort Square Center Bld. 18F 
Daerung Post Tower III, 508 
92240 Malakoff  
2-3-12, Higashi-shinagawa, 
Guro-gu, Guro-dong, 182-4 
France 
Shinagawa-ku 
Seoul, 152-790 
Tel:  +33 (0)1 42 31 40 00 
J-140-0002 Tokyo 
Republic of Korea 
Fax: +33 (0)1 42 31 40 09 
Tel.: +81 3 5769 6970    
Tel.: +82-2-2028-0600 
Email: information@vector-france.fr 
Fax: +81 3 5769 6975 
Fax:   +82-2-2028-0604 
 
Email: info@vector-japan.co.jp 
Email: info@vector-korea.com 
 
 
 
13 
Application Note  AN-ISC-2-1081 
 

---

1.1.15 - AN-ISC-8-1056_CANbedded_Program_Stack_Usages

 
CANbedded Program-Stack usage 
Version 1.0 
2007/01/08  
Application Note  AN-ISC-8-1056 
 
 
 
Author(s) Andreas 
Raisch 
Restrictions Customer 
confidential 
- subject to prior approval by PSC 
Abstract 
This application note provides basic information on the (program-) stack consumption of 
Vector's CANbedded communication components. 
 
 
Table of Contents 
 
1.0 
Overview ..........................................................................................................................................................1 
1.1 
Definition “The Stack”....................................................................................................................................1 
1.2 
Embedded System Stack Handling...............................................................................................................2 
1.3 
Stack-Usage Approach in CANbedded.........................................................................................................3 
1.3.1 
Example ......................................................................................................................................................3 
1.3.2 
Configuration Aspects.................................................................................................................................5 
1.4 
Calculating and Measuring Stack Need........................................................................................................5 
2.0 
Summary..........................................................................................................................................................5 
3.0 
Contacts...........................................................................................................................................................6 
 
 
 
1.0 Overview 
This application note provides basic information on the (program-) stack consumption of Vector’s CANbedded 
communication components. 
1.1  Definition “The Stack” 
In computer science, a call stack is a special stack, which stores information about the active subroutines of a 
computer program. (The active subroutines are those, which have been called but have not yet completed 
execution by returning.) This kind of stack is also known as a program stack, execution stack, control stack, 
function stack or run-time stack and is often abbreviated to just "the stack". 
 
The actual details of the stack in a programming language depend upon the compiler, operating system, and the 
available instruction set. 
 
As noted above, the primary purpose of the stack is: 
•  Storing the return address – When a subroutine is called, the location of the instruction to return to 
needs to be saved somewhere.  
 
A stack may serve additional functions, depending on the language, operating system and machine environment. 
Among them can be: 
•  Local data storage – A subroutine frequently needs memory space for storing the values of local 
variables, the variables that are known only within the active subroutine and do not retain values after it 
returns.  
 1  
Copyright © 2007 - Vector Informatik GmbH 
Contact Information:   www.vector-informatik.com   or ++49-711-80 670-0 

---

 
 
CANbedded Program-Stack usage 
 
 
 
 
 
•  Parameter passing – Subroutines often require that values for parameters must be supplied to them by 
the code which calls them and it is not uncommon that space for these parameters may be laid out in the 
stack. Generally if there are only a few small parameters, processor registers will be used to pass the 
values. The stack works well as a place for these parameters, especially since each call to a subroutine, 
which will have differing values for parameters, will be given separate space on the stack for those values. 
•  Other return state – Besides the return address, in some environments there may be other machine or 
software states that need to be restored when a subroutine returns. This might include things like 
processor registers, privilege level, exception handling information, arithmetic modes and so on. If needed, 
this may be stored on the stack just as the return address is. 
 
The typical stack is used for the return address, locals, and parameters (known as a call frame). In some 
environments there may be more or fewer functions assigned to the stack.  
A stack is composed of stack frames (sometimes called activation records). Each stack frame corresponds to a call 
to a subroutine, which has not yet terminated with a return. For example, if a subroutine named DrawLine is 
currently running, having just been called by a subroutine DrawSquare, the top part of the stack might be laid out 
like this: 
 
The stack frame at the top of the stack is for the currently executing routine. In the most common approach the 
stack frame includes space for the local variables of the routine, the return address back to the routine's caller, and 
the parameter values passed into the routine. The memory locations within a frame are often accessed via a 
register called the stack pointer, which also serves to indicate the current top of the stack. Alternatively, memory 
within the frame may be accessed via a separate register, often termed the frame pointer, which typically points to 
some fixed point in the frame structure, such as the location for the return address. 
Stack frames are not all of the same size. Different subroutines have differing numbers of parameters, so that part 
of the stack frame will be different for different subroutines, although usually fixed across all activations of a 
particular subroutine. Similarly, the amount of space needed for local variables will be different for different 
subroutines.  
[Source: Wikipedia] 
 
1.2  Embedded System Stack Handling 
The bandwidth of embedded system architectures and also the used µC (and compilers) results in a huge variety 
of stack handling approaches. 
The simplest approach is often valid, when no operating system (OS) is used. In such a case the stack is simply a 
 
2 
Application Note  AN-ISC-8-1056 
 

---

 
 
CANbedded Program-Stack usage 
 
 
 
 
 
reserved RAM area used by the whole system. 
If an OSEK/OS or AUTOSAR OS is used, the stack handling depends on the available features in the OS and the 
underlying µC. Each OS task has usually its own stack but can share this stack if some preconditions are kept with 
other tasks. Providing one or more own stacks for interrupts can reduce the stack need of the OS tasks, too.  
The stack need of an embedded system depends also on the specific handling for interrupts: 
•  Storing of CPU registers on the stack or simply switching to a different stack bank 
•  Supporting/using nested interrupts; i.e. interrupts can cause multiple store actions to the stack 
•  Configuring own stack(s) for interrupts or using the stack of the currently running OS task (or other 
interrupt) 
Please note that for most implementations the stack pointer starts at a high address and grows to lower addresses. 
1.3  Stack-Usage Approach in CANbedded 
The CANbedded architecture is optimized for so-called deeply embedded systems with limited RAM and runtime in 
real-time systems. As a result of this, the architecture is gained to be a good compromise between  
•  ROM usage (multiple implementation of same behavior vs. in-lining or calling functions) 
•  RAM usage (static parameters vs. local parameters on the stack; calling a function vs. implementing 
something short twice, …) 
•  Runtime consumption (calling a function needs more time than local handling) 
 
A CANbedded function shall therefore  
•  have only few arguments (none, 1 or 2, very very rarely more than 2 parameters) 
•  be implemented in a way that local data stored on the stack is minimized 
•  call no other functions unless it is necessary due to layered architecture 
 
Most CANbedded API functions are implemented in a way that only flags are set which are evaluated on a cyclic 
function to prevent too deep function call trees (and with this an increased stack need). 
An additional task of the CANbedded communication components is the separation of the interrupt driven 
hardware handling and the task-level view of the application. To be able to react on communication events 
correctly, parts of the handler implementation are executed on interrupt level and parts are executed on task level. 
Which stack and how much stacks are used for the task and the interrupt context depends on the underlying 
system (see chapter 1.2 for details). 
1.3.1 Example 
A typical example for such a CANbedded implementation is a transport protocol, where the reaction on incoming 
events has to be fast whereas the timeout and state handling can be slower. The implementation will therefore be 
split in a function called within the CAN RX interrupt for fast actions and a cyclic called function for the slower ones. 
The same is true for the next upper layer, the diagnostic layer. See Figure 2 for details how the diagnostic layer 
handles the separation of RX event notification in CAN ISR context and further handling on task context. 
As a result, the call tree of the RX event handling in ISR context stops latest on diagnostic layer level. All further 
handling (including application calls) is processed a few milliseconds later from task level with only very few 
function calls on the stack. 
 
3 
Application Note  AN-ISC-8-1056 
 

---

 
 
CANbedded Program-Stack usage 
 
 
 
 
 
osCAN
Application
Diagnostics
Layer
Universal
Measure-
Interaction 
Network
ment
Layer
Management
And 
Communication
Calibration
Control
Transport Protocol
Protocol
Layer
CAN Driver
CAN Controller
Transce
Transc iver
CAN Bus
 
Figure 1 Example CANbedded Stack with CAN Driver, TP and Diagnostic Layer as the largest call-tree 
 
Data 
Da
Eve
Ev nt 
ready 
Cyclic 
han
ha dler
flag
hand
ha
l
nd er
CAN 
CAN
Transp
Trans ort
Diagnostics
osti                          
                    
Application
Driver
Protocol
Protoc
Laye
Lay r
Further handling
RX o
RX f TP frame
am
Optional call to application
unknown to std. SW
Copy RX data
 dat
Check RX
data ready
Further handling
RX o
RX f last TP frame
am
Optional call to application
unknown to std. SW
Copy RX data
 dat
Indicate RX data ready
Check RX
data ready
PreHandler
Further handling
unknown to std. SW
MainHandler
Further handling
unknown to std. SW
ISR/Event context
Task context
 
Figure 2 Example call-tree for diagnostic data reception 
 
 
4 
Application Note  AN-ISC-8-1056 
 

---

 
 
CANbedded Program-Stack usage 
 
 
 
 
 
1.3.2 Configuration 
Aspects 
The configurations of the CANbedded components have a large impact on the stack needs. There is a customer 
specific, static setup of CANbedded components which interact together to fulfill the OEM requirements. I.e. the 
CAN driver always informs e.g. the transport layer if a specific CAN frame is received and the transport layer 
informs the diagnostic layer if the full message is received. This call sequence is preconfigured by Vector, 
nevertheless, the software supports multiple points (callbacks) where customer specific hooks can be included. 
This customer hooks have additional influence to the stack needs. 
Another very important configuration parameter is the decision if the RX/TX handling shall be processed in 
interrupt or on task context. If it is processed on task context, the stack need can be calculated easier than when 
the handling is performed with interrupts. 
In an ECU with one CAN bus, an interaction layer (IL), a network management (NM), a transport layer (TP) and a 
diagnostic component, the RX path of incoming diagnostic CAN messages has usually the largest call tree form 
communication point of view and therefore the highest stack need. 
1.4  Calculating and Measuring Stack Need 
Exactly calculating the stack needs is a difficult and error-prone task. Therefore the stack size is often estimated 
based on the environmental conditions described in chapter 1.2 and a safety value of 10% to 20%, sometimes 
100%, is added to the result. 
If an operating system is used, this system usually provides means to measure stack usage and test stack 
consistency. OSEK/OS and AUTOSAR OS for instance provides such means to check the stack with each OS 
action and also to initialize the stack with patterns so the worst case usage for a given scenario can be found. 
When using such a method, it is important to analyze upfront the worst case call trees and make sure they have 
happened during test execution, too. This implies also “special” scenarios like “ECU in diagnostics”, “ECU with high 
I/O interrupt load”, occurrence of OSEK category 1 and 2 interrupts at the same time, … 
2.0 Summary 
As a result of all this effects, no detailed figure for the concrete stack usage of the CANbedded communication 
components can be given upfront of the real usage in an ECU project. 
Vector offers different levels of support to customers, starting from telephone hotline for the more simple questions, 
integrating the CANbedded communication components and other software up to analyzing your ECU setup as a 
separate project work. 
 
Note:  
Please be aware that due to all the points mentioned in this application note Vector can not finally 
list the stack needs of the CANbedded communication components in your project. The concrete 
layout and dimension of the stack(s) in an ECU project is the task of the system integrator.  
 
 
5 
Application Note  AN-ISC-8-1056 
 

---

 
 
CANbedded Program-Stack usage 
 
 
 
 
 
3.0 Contacts 
 
 
 
 
Vector Informatik GmbH 
Vector CANtech, Inc. 
VecScan AB 
Ingersheimer Straße 24 
39500 Orchard Hill Pl., Ste 550 
Lindholmspiren 5 
70499 Stuttgart 
Novi, MI  48375 
402 78 Göteborg  
Germany 
USA 
Sweden 
Tel.: +49 711-80670-0 
Tel:  +1-248-449-9290 
Tel:  +46 (0)31 764 76 00 
Fax: +49 711-80670-111 
Fax: +1-248-449-9704 
Fax: +46 (0)31 764 76 19  
Email: info@vector-informatik.de 
Email: info@vector-cantech.com 
Email: info@vecscan.com 
 
Vector France SAS 
Vector Japan Co. Ltd. 
 
168 Boulevard Camélinat 
Seafort Square Center Bld. 18F 
92240 Malakoff  
2-3-12, Higashi-shinagawa, 
France 
Shinagawa-ku 
Tel:  +33 (0)1 42 31 40 00 
J-140-0002 Tokyo 
Fax: +33 (0)1 42 31 40 09 
Tel.: +81 3 5769 6970    
Email: information@vector-france.fr 
Fax: +81 3 5769 6975 
 
Email: info@vector-japan.co.jp 
 
 
 
6 
Application Note  AN-ISC-8-1056 
 

---