ST AN2628 Application note
AN2628
Application note
Programming ST10F27x CAN interrupt drivers
Introduction
This application note describes the CAN interrupt drivers of the ST10F27x and provides
programming e xamples that can be used to define interrupt schemes and write interrupt
drivers. Two C-CAN modules are implemented on ST10F27x, mapped on XBUS.
Interrupt sources, the way the sources of interrupts are identified and the two methods of
handling interrupts are described: One using the hardware features of the CAN modules
and the other through polling internal sources.
Programming the CAN interrupt drivers through CAN hard ware features uses the RXIE and
TXIE bits of each message object. All 32 message objects are accessed through interface
registers. Two sets of register are available for each module, fo r e xample CANxIF1 registers
can be used to read from a message object whereas CANxIF2 registers can be used to
write into a message object. Whenev er a message is tr a nsmitt ed or r eceived by a message
object, the corresponding interrupt is serviced according to its priority (based on the value of
IntId). This method requires minimum CPU overhead and is t he preferred method for most
applications.
CAN polling generates an interrupt whene ve r a successful transmission or reception occurs .
Polling is high in CPU overhead, as the CPU is interrupted every time a message is
acknowledged on the CAN bus. Therefore, programming the interrupt driver using polling is
only recommended for small networks.
Sample programs are provided for each method as examples.
October 2007 Rev 1 1/28
www.st.com
Contents AN2628
Contents
1 Interrupt sources and identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Global interrupt sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Individual interrupt sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Status interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Error interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Message-specific interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Handling interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Message-specific interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Bus-off interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Programming through CAN hardware features . . . . . . . . . . . . . . . . . . 10
4 Programming through polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A Register description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
A.1 Global interrupt control registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
A.2 CAN control register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A.3 CAN status register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix B Message object register definition. . . . . . . . . . . . . . . . . . . . . . . . . . 23
B.1 CCAN_drvs.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2/27
AN2628 List of tables
List of tables
Table 1. XIR0SEL register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 2. XIR1SEL register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Table 3. XIR3SEL register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Table 4. CAN1CR and CAN2CR registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Table 5. CAN1SR and CAN2SR registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Table 6. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3/27
Interrupt sources and identification AN2628
1 Interrupt sources and identification
Interrupts generated by the CAN modules can come from dif f er ent sources: Global interrupt
sources and individual interrupt sources.
1.1 Global interrupt sources
Four interrupt control regist ers (XIRxSEL, x = 0, 1, 2, 3) are pro vided in orde r to generate an
interrupt from different event sources. Each module is linked to its corresponding XPxIC
register (x = 0, 1, 2, 3). Note that an event source can be connected to several XIRxSEL
registers. In particular, each CAN1 and CAN2 event is connected on two interrupt lines:
● CAN1: XP0INT, XP3INT
● CAN2: XP1INT, XP3INT
The new 16-bit register XIRxSEL (x = 0, 1, 2, 3) is divided into two parts:
● Byte high (XIRxSEL[15:8]) Interrupt enable bits
● Byte low (XIRxSEL[7:0]) Interrupt flag bits
When different sources submit an interrupt request, the enable bits (Byte High of XIRxSEL
register) define a mask to select the sources to be associated with the unique available
vector. If more than one source is enabled to issue the request, the service routine must
identify the real event to be serviced. This can easily be done b y ch ec king the f lag bits (Byte
Low of XIRxSEL register). Note tha t the f lag bit pro vide s information about ev ents which are
not currently serviced by the interrupt controller (since masked through the enable bits),
allowing effective software management even when the related interrupt request cannot be
served: A periodic polling of the flag bits may be implemented inside the user application.
Figure 1. X-Interrupt basic structure
70
Flag[7:0]
IT Source 7
IT Source 6
IT Source 5
IT Source 4
IT Source 3
IT Source 2
IT Source 1
IT Source 0
Enable[7:0]
15 8
4/27
XIRxSEL[7:0] (x = 0, 1, 2, 3)
XPxIC.IR (x = 0, 1, 2, 3)
XIRxSEL[15:8] (x = 0, 1, 2, 3)
AN2628 Interrupt sources and identification
In summary: To enable CAN interrupt to the CPU, set bit IE in the CAN control register,
corresponding enable bit in the XIRxSEL register (x = 0, 3 for CAN1, x = 1, 3 for CAN2) and
bit XPxIE in the X-peripherals interrupt control register XPxIC. Please refer to Appendix A:
Register description.
1.2 Individual interrupt sources
The CAN controller distinguishes three different individual interrupt sources:
● Status interrupts
● Error interrupts
● Message-specific interrupts
1.2.1 Status interrupts
Status interrupts are generated after a status change of the CAN modules is indicated by
the flags in the status register. Status interrupts are enabled by setting bit SIE in the control
register.
Status interrupts are caused by:
● Successful transmission from the CAN modules (TxOK is set) of any message from
message objects
● Reception of a message on the CAN bus - RxOK is set after an ac kno wled ge of a CAN
frame from the CAN module - this CAN frame may not correspond to any message
object identifier.
● Occurrence of an error on the CAN bus during a message transfer (LEC bit field is
updated); this error may not come from the CAN module itself but has at least been
detected by the CAN modules. LEC code 7 is not used and may be written to 7 by the
CPU to check for updates.
TxOK, RxOK, LEC can be read from the status register.
Note: Enabling the Status Change Interrupt causes an in terrupt to the CPU every time a message
is acknowledged on the CAN bus. For this reason, Status Change Interrupt should be
disabled in most applications except where a close monitor on the bus activity is required
(for example, after an early warning).
1.2.2 Error interrupts
Error Interrupts are generated once pre defined error conditions are reach ed. Error interrupts
are enabled by setting bit EIE in the control register. Error interrupts are caused by:
● Warning status (EWarn is set) indicating that at least one of the error counters has
reached the error warning limit of 96
● Bus-off (BOff is set) indicating that the CAN controller is in bus-off state
EWarn and BOff can be read from the st atus register.
5/27
Interrupt sources and identification AN2628
1.2.3 Message-specific interrupts
Message-specific interrupts are generated by each message object. They are individually
enabled by setting bit TXIE (for transmission) or RXIE (for reception), or both, in th e CAN
message objects.
Message-specific interrupts are caused by:
● Reception of a message (data frame or remote) into the corresponding message
object.
● Successful transmission (data frame or remote) of the corresponding message object.
Bit ‘IntPnd’ in each message object indicates that the corresponding message object has
generated an interrupt request.
Note: Refer to Sectio n 2.1: Message-specific interrupts for further information on decoding
message-specific interrupts.
Identifying interrupt sources
The value of IntId code in the Interrupt register identifies the interrupt source; the Status
Interrupt has the highest priority. Among the message interrup ts, the Messa g e Ob jec t’s
interrupt priority decreases with increasing message number. A message interrupt is
cleared by clearing the Message Object’s IntPnd bit. The Status Interrupt is cleared by
reading the Status register.
● IntId = 0000h: Indicates that no (or no more) interrupt/s is/are pending.
● IntId = 0001h to 0020h: Indicate a Message-specific Reception or Transmission from
message object 1 to 32.
● IntId = 8000h: Indicates that a Status Change Interrupt or an Error Interrupt is pending.
6/27
AN2628 Handling interrupts
2 Handling interrupts
CAN interrupt-source priority decreases with increasing IntId code (except for Status
Change Interrupt). The IntId code is taken into account when identifying the interrupt
source. For example, if bits SIE and TXIE have been set, the successful transmission of a
message can cause two independent interrupt requests. While a status interrupt (highest
priority) is serviced, a message-specific interrupt remains pending (bit IntPnd of the
corresponding object is only cleared by writing a 0 value in the Message Object through
interface registers).
There are two ways to handle interrupts: One method relies on the hardwired priority of the
message object, the other method uses polling. These methods are described in Section 3:
Programming through CAN hardware features on page 10 and Section 4: Programming
through polling on page 13.
Although these two methods identify the inter rupt source in diffe rent wa ys, the y handle low er
level events in the same way. These lower level events are described in the following
sections.
2.1 Message-specific interrupts
When a message object causes an interrupt, the message object can be identified in two
ways:
● From the IntId bit value
● By reading interrupt pending regis ter s
The direction of bit DIR must be considered in the decoding phase:
Message objects with the message direction = ‘receive’ (bit DIR is reset)
These can be caused by:
● Successful transmission of a remote frame (TXIE must have been set)
● Successful reception of a data frame (RXIE must have been set)
The bit ‘NewDat’ can be used to differentiate between the two interrupt causes:
● NewDat = 1: Reception of a data frame
● NewDat = 0: Successful transmission of a remote frame
Message objects with message direction = ‘transmit’ (bit DIR is set)
These can be caused by:
● Reception of a remote frame with same identifier (RXIE must have been set)
● Successful transmission of a data frame following a CPU request or remote request
(TXIE must have been set)
Changing the message configuration
To change the message configuration during normal operation, set MsgVal to ‘not valid’ (bit
MsgVal = 0). When the new configura tion is set into the message object registers, bit
MsgVal can be reset.
Example - software decoding of message-specific interrupts
7/27
Handling interrupts AN2628
Note: This example assumes that a ‘switch on IntId’ instruction is placed at the beginning of the
interrupt driver:
case (intid): // Message n specific interrupt
CANxIF1CM = 0x7F; // Transfer entire message into inference
CANxIF1CR = intid; // register and clear IntPnd and NewDat
CANx_WAIT_FOR_IF1;
if (CANxIF1A2 & IF_DIR) // direction = transmit
{
if (CANxIF1MC & IF_NEWDAT) // remote received provided that
// UMask =1 and RmtEn = 0
{.....} // procedure to handle answer to remote
else
{.....} // procedure to handle transmit interrupts
}
else // direction = receive
{
if (CANxIF1MC & IF_NEWDAT) // NewDat is set
{.....} // procedure to handle data receive interrupt
else
{.....} // a remote frame was successfully transmitted
}
break;
2.2 Bus-off interrupts
Each transfer erro r detected on the CAN bus (t hough not nece ssarily generated by th e CAN
module) increments one of the two error counters (receive error counter and transmit error
counter). If one of these counters reaches the value of 96, bit EWarn is set. If enabled by
bits EIE and IE, an error interrupt is generated. If the transmit error counter exceeds the
value of 255, bit BOff is set. If enabled by bits EIE and IE, this generates an error interrupt.
Furthermore, when the device goes into the bus-off state, bit INIT is set and all actions on
the bus are stopped immediately.
The bus-off recovery sequence can be initiated from the bus-off state. During the bus
recovery sequence, the CAN module monitors the recovery sequence.
● The bus-off recovery sequence is started by resetting bit INIT.
● Bit0Error is set every time a sequence of 11 recessive bits is detected. Bit0Error
indicates that the CAN bus is not stuc k at dominant or not co ntinuously disturbe d. If bits
SIE and IE are set, a status interrupt is generated after each sequence.
● The recovery sequence cannot be shortened by setting or resetting bit INIT.
8/27
AN2628 Handling interrupts
case 0x8000: // IntId=0x8000 for status and error interrupt
{
if (CANxCR & EIE) // error interrupt are enabled
{
if (CANxSR & EWRN) // EWarn is set
{ ......} // procedure for Early warning
if (CANxSR & BOFF) // BOff is set
{ .......} // bus-off procedure
}
break;
9/27
Loading...