Datasheet

CAN: Controller Area Network Lab using ST STM32 Cortex-M processors. www.keil.com

Bonus TIPS: Here some items NOT part of the CAN specification but might prove helpful in your system:

1) Transmitting data sets greater than 8 bytes:

Clearly, transmitting a data set greater than 8 bytes will require multiple frames and this will require some planning. Such

schemes can become very complicated as they have to deal with a wide-ranging set of contingencies. If you can focus on a

narrow requirement set, design of a simpler protocol is possible.

Most current schemes use the first data byte to contain the number of total data bytes to follow plus a counter to help

determine which data byte is which. The ID usually identifies the node plus whether it is a request or response message. If

you want to use an existing protocol see ISO 15765. This is what automobiles use. OBDII diagnostics on vehicles also use

this protocol. OBDII is an example where one message can be comprised of many CAN frames. Diagnostics are common.

2) Periodic, Request/Response and Command Frames:

Periodic: This technique sends a frame out periodically – several times a second is usual. This frame will contain data that

any node can use if it wants to and is identified by its ID. Examples are speed, position, pressure and events. Messages that

are lost (usually because the processor fails to empty the controller input queue fast enough) are replaced quickly.

Request/Response: A node sends out a frame requesting certain specified information. Any other nodes that have the

requested information then put it on the bus. The ID identifies the Request and the Response frames by changing one bit of

the ID. An example is that ID 0x248 is a Request frame and 0x648 is its Response frame. The Request frame data bytes

indicate what information is requested. The Response frame will contain the requested information or an error indication.

Command: A frame commanding some event to be performed. The ID usually contains the address of the commanded node

and the data bytes the actual command(s). An ID signifying a broadcast message will be sent to all nodes. Technically all

nodes can see all messages anyhow: but this can allow a message to get past a filter or from being ignored by a node.

Sometimes an Acknowledge frame will be returned. Note: This is not the ACK bit.

TIP: You might want to consider a blend of these types of traffic depending on your system’s needs.

3) Time-outs:

Automotive CAN networks use time-outs and this concept is easily and effectively transferred to systems in other fields. A

time-out occurs when a node fails to respond to a request in a timely fashion. Time-outs are handled completely by software

and not by the CAN specification. A time-out is helpful to recover from problems with the network such as severe bus

errors, catastrophic bus faults, faulty nodes, intermittent connections or a user abort.

The result is usually a limp-home mode where a node will attempt to run itself without information from the rest of the

network. In some cases, a punitive limp-home mode is entered that forces the user to perform repairs. Another result is to

revert back to normal operation. This is common when a user stops making inputs for a long time. You do not want a

system to sit in a configuration mode forever. You must control your processes.

A time-out consequence can be a system RESET or less likely, a shutdown. In any case, notification to an operator is a very

good idea. In extreme circumstances, such as a remote system not accessible: a mode to download new firmware is effective.

A good example is if the vehicle transmission fails and proper gear shifting becomes impossible. In this case, the module

will go into limp-home mode and the transmission might be put into one gear such as second to allow the vehicle to still be

driven. This can be for safety reasons or to prevent further damage to the power train. Another example of a time-out is

when the setting of the clock by a user is started but stopped midway. After the time-out, the clock will revert to its normal

operating mode.

Another good example is the MARS Rovers. If communication stopped for a certain period of time: it will be assumed that a

catastrophic event has occurred. Hopefully this will be a software bug and not a hardware failure. The Rover will go into a

special mode where it listens for a software update or if really bad, a complete firmware replacement to be sent from Earth.

Heart-beats and Address Claiming: The other side to a time-out is a heart beat. Periodic messages can be sent out to

determine that all nodes are on the bus and active. CANopen uses such heart-beats. J1939 has a software mechanism where

each node can declare itself to be on the bus and be recognized by the other nodes. This is called “Address Claiming” and

occurs during the system startup. None of these mechanisms are provided by the CAN specification but rather by your

software or a suitable specification or protocol.