Statement of Intent

The Controller Area Network (CAN), developed in the 1980s by Robert Bosch [1], is one of the most important networks in the field of real-time embedded systems; allowing for short real-time messages to be transmitted and received at speeds of up to 1 Mbit/sec.

The nature of CAN permits messages to be transmitted to multiple nodes simultaneously as CAN passes messages with a specific identifier, not messages with a specific destination. Each node chooses whether or not it will act upon a specific message by filtering the message's identifier. This can be done using either hardware or software. Although this technology was originally developed several decades ago, it is still widely used today in control applications for aircrafts, factories and automobiles.

This project aims at investigating, designing and implementing such a network and a software library + API to complement the previous SPUTNIC [Single-chip Processor Unit Together with Network Interface Chips] Projects which were based on the Motorola HCS12 single-chip processor and undertaken in 2002/03 and 2003/04. The creation of software libraries and an API will allow future SPUTNIC projects to utilise the capabilities of the Controller Area Network .

Furthermore, this project will also investigate the use of UDP/IP and/or TCP/IP as a gateway to the Controller Area Network (CAN) as well as the possible limitations introduced by using such protocols.

[1] CAN Specification Version 2.0, Parts A and B, by Robert Bosch GmbH

UDP/IP and/or TCP/IP (optional)

Been looking more into the original idea of using TCP/IP as a bridge, however, not sure if it's the best idea, so will also look at UDP/IP ;-)

Further Notes on Demos

Since part of the project is to help other students understand how to use the CAN interface more easily, as well as giving them some form of API to use, I feel that giving a collection of demos that show all the different uses of the CAN (and explained) would be a lot more useful than implementing one massive demo which could cloud the understanding of the CAN API. Obviously, there is room for larger demos, however, initially I will not focus on them.

Simple Demo

Since it popped into my head, might as well note it.
A very quick and simple demo could be done by having 2 or more chips linked with the CAN network along with using the onboard LEDs and buttons. A simple master node could be created that counts the number of times a button is pressed on ANY of the chips (i.e. the number of times messages are passed to it) that are connected to the CAN bus. Could be further expanded by telling the other chips that the master node had recieved the message, or could broadcast the new total count on the master node etc...

Bosch specification. V2.0
Standard CAN (V2.0A) 11 bit identifiers.
Extended CAN (V2.0B) 29 bit identifiers.

Bit Timing

http://www.freescale.com/files/
microcontrollers/doc/app_note/AN1798.pdf

33388 FAULT TOLERANT CAN INTERFACE

Yipee, as I already know the development board has CAN, however, the CAN physical layer was not obvious at all.

Using the schematics and following some copper, I can confirm that the development board has one physical interface. Another physical interfaces can be added, however, that will involve some soldering ;-)

CAN Physical layer details:
- Low-speed
- Fault tolerant CAN physical interface device
- Compatible with CAN 2.0 A and B protocals. (Very important)
- Very low sleep/standby current (15mA typical)
- Supports communication speeds up to 125 kB/s (Min: 10 kB/s)
- -40°C ≤ TA ≤ 125°C

Some Features:
- Automatic switching to single wire mode in the event of bus failures with
return to differential mode if bus failures disappear
- Supports unshielded twisted pair bus

PDFs
http://www.freescale.com/files/
analog/doc/data_sheet/MC33388.pdf

NOTE: High Speed 1.0Mbps CAN Interfaces are available too MC33742

Health & Safety (Risk Assessment)

Need to do a risk assessment for project.
Only real possible danger is from electrical devices, like, non-covered chips etc...
I've just got to make sure they are powered off when I'm connecting devices to them or playing about with them.

Furthermore, keep cups of coffee away from them too ;-)

Need to fill out this form
http://www.eee.strath.ac.uk/safety/risk-assessment-form.pdf

MSCAN Block Guide v02.15

Essential read
http://www.freescale.com/files/
microcontrollers/doc/ref_manual/S12MSCANV2.pdf

MSCAN on the MC9S12DP256 compared with HC12 family

http://www.freescale.com/files/
microcontrollers/doc/app_note/AN2011.pdf

MSCAN Wake-up

MSCAN Wake-up (Low Power Consumption)
http://www.freescale.com/files/
microcontrollers/doc/app_note/AN2255.pdf

Error Detection

The MSCAN is able to detect five types of errors. They are:
1. Bit Error — detected by the MSCAN’s transmit state machine
2. Stuff Error — detected by the MSCAN’s receiver state machine
3. CRC Error — detected by the MSCAN’s receiver state machine
4. Form Error — detected by the MSCAN’s receiver state machine
5. Acknowledgement Error — detected by the MSCAN’s transmitter state machine

Bit Error
A node’s transmitter detects a bit error if the bit value monitored is different from the bit value transmitted. An exception to this is when sending a recessive [1] bit and receiving a dominant [0] bit during the arbitration field or the ACK slot. Also, a node transmitting a PASSIVE Error Flag and receiving a dominant [0] bit doesn’t interpret this as a Bit Error.

Stuff Error
Whenever five consecutive bits of equal value are transmitted, an extra bit of complementary value is automatically inserted into the bit stream. This provides edges for clock resynchronization. The receivers automatically destuff the extra bit of complementary value. So, when a receiver detects a 6th consecutive equal level value (six dominant [0] bits or six recessive [1] bits) during a message field that should be encoded by bit stuffing a stuff error is detected.

CRC Error
A CRC (Cyclic Redundancy Check) error is detected by the node’s receiver if the CRC calculated by the receiver is different from the CRC received in the message.

Form Error
The node’s receiver detects a Form Error if a fixed form bit field contains one or more illegal bits. For example, a fixed form bit field would be the arbitration field which can be 12 (standard mode) / 32 (extended mode) bits in length; or the control field which has two reserved bits (r1 and r0) that need to be sent out as two dominants [0] in a row; or the CRC field which has the CRC Delimiter and needs to be a recessive [1] bit.

Acknowledgement Error
A node’s transmitter detects an Acknowledge Error if it doesn’t receive a dominant [0] bit during the ACK Slot. A dominant [0] bit in the ACK Slot indicates an acknowledgment occurred. The ACK Slot is in the Acknowledge field of the data frame. *Figure 19 provides a reminder of what the data frame consists of and shows what is inside the Acknowledge field.

*Figure 19 on page 2 of pdf

Resets and Interrupts

Vector Table - lists interrupt sources and vectors in default order of priority.
V. Add. | Interrupt Src| CCR Mask | Local Enable | HPRIO Value to Elevate

$FFB6, $FFB7 | CAN0 | wake-up | I-Bit | CAN0RIER (WUPIE) | $B6
$FFB4, $FFB5 | CAN0 | errors | I-Bit | CAN0RIER (CSCIE, OVRIE) | $B4
$FFB2, $FFB3 | CAN0 | receive | I-Bit | CAN0RIER (RXFIE) | $B2
$FFB0, $FFB1 | CAN0 | transmit | I-Bit | CAN0TIER (TXEIE2-TXEIE0) | $B0
$FFAE, $FFAF CAN1 wake-up I-Bit CAN1RIER (WUPIE) $AE
$FFAC, $FFAD CAN1 errors I-Bit CAN1RIER (CSCIE, OVRIE) $AC
$FFAA, $FFAB CAN1 receive I-Bit CAN1RIER (RXFIE) $AA
$FFA8, $FFA9 CAN1 transmit I-Bit CAN1TIER (TXEIE2-TXEIE0) $A8
$FFA6, $FFA7 CAN2 wake-up I-Bit CAN2RIER (WUPIE) $A6
$FFA4, $FFA5 CAN2 errors I-Bit CAN2RIER (CSCIE, OVRIE) $A4
$FFA2, $FFA3 CAN2 receive I-Bit CAN2RIER (RXFIE) $A2
$FFA0, $FFA1 CAN2 transmit I-Bit CAN2TIER (TXEIE2-TXEIE0) $A0
$FF9E, $FF9F CAN3 wake-up I-Bit CAN3RIER (WUPIE) $9E
$FF9C, $FF9D CAN3 errors I-Bit CAN3RIER (TXEIE2-TXEIE0) $9C
$FF9A, $FF9B CAN3 receive I-Bit CAN3RIER (RXFIE) $9A
$FF98, $FF99 CAN3 transmit I-Bit CAN3TIER (TXEIE2-TXEIE0) $98
$FF96, $FF97 CAN4 wake-up I-Bit CAN4RIER (WUPIE) $96
$FF94, $FF95 CAN4 errors I-Bit CAN4RIER (CSCIE, OVRIE) $94
$FF92, $FF93 CAN4 receive I-Bit CAN4RIER (RXFIE) $92
$FF90, $FF91 CAN4 transmit I-Bit CAN4TIER (TXEIE2-TXEIE0) $90

System Clock Description

Page 69 onwards
http://www.ece.unh.edu/courses/ece612/9S12DP256BDGV2.pdf

Need to use the oscillator clock to set different Bit Rates etc...

Detailed MSCAN Foreground Receive and Transmit Buffer Layout

Page 40 onwards...
http://www.ece.unh.edu/courses/ece612/9S12DP256BDGV2.pdf

Memory Map

$0000 - $0017 CORE (Ports A, B, E, Modes, Inits, Test) 24
$0018 - $0019 Reserved 2
$001A - $001B Device ID register (PARTID) 2
$001C - $001F CORE (MEMSIZ, IRQ, HPRIO) 4
$0020 - $0027 Reserved 8
$0028 - $002F CORE (Background Debug Mode) 8
$0030 - $0033 CORE (PPAGE, Port K) 4
$0034 - $003F Clock and Reset Generator (PLL, RTI, COP) 12
$0040 - $007F Enhanced Capture Timer 16-bit 8 channels 64
$0080 - $009F Analog to Digital Converter 10-bit 8 channels (ATD0) 32
$00A0 - $00C7 Pulse Width Modulator 8-bit 8 channels (PWM) 40
$00C8 - $00CF Serial Communications Interface 0 (SCI0) 8
$00D0 - $00D7 Serial Communications Interface 0 (SCI1) 8
$00D8 - $00DF Serial Peripheral Interface (SPI0) 8
$00E0 - $00E7 Inter IC Bus 8
$00E8 - $00EF Byte Data Link Controller (BDLC) 8
$00F0 - $00F7 Serial Peripheral Interface (SPI1) 8
$00F8 - $00FF Serial Peripheral Interface (SPI2) 8
$0100- $010F Flash Control Register 16
$0110 - $011B EEPROM Control Register 12
$011C - $011F Reserved 4
$0120 - $013F Analog to Digital Converter 10-bit 8 channels (ATD1) 32
$0140 - $017F Motorola Scalable Can (CAN0) 64
$0180 - $01BF Motorola Scalable Can (CAN1) 64
$01C0 - $01FF Motorola Scalable Can (CAN2) 64
$0200 - $023F Motorola Scalable Can (CAN3) 64
$0240 - $027F Port Integration Module (PIM) 64
$0280 - $02BF Motorola Scalable Can (CAN4) 64
$02C0 - $03FF Reserved 320
$0000 - $0FFF EEPROM array 4096
$1000 - $3FFF RAM array 12288
$4000 - $7FFF Fixed Flash EEPROM array incl. 0.5K, 1K, 2K or 4K Protected Sector at start 16384
$8000 - $BFFF Flash EEPROM Page Window 16384
$C000 - $FFFF incl. 0.5K, 1K, 2K or 4K Protected Sector at end and 256 bytes of Vector Space at $FF80 - $FFFF 16384

CAN on Boards

Five 1M bit per second, CAN 2.0 A, B software compatible modules
– Five receive and three transmit buffers
– Flexible identifier filter programmable as 2 x 32 bit, 4 x 16 bit or 8 x 8 bit
– Four separate interrupt channels for Rx, Tx, error and wake-up
– Low-pass filter wake-up function
– Loop-back for self test operation

Hopefully Objectives

Original Spec described the cluster to have a 'Master':
A master node is possible (by design) at the application layer, however, the nature of the CAN network allows multiple masters, no node is specifically used to control the flow of the traffic. Every node can choose to act on a message or ignore it (again either done at the application layer, or can be done at the data link layer (check that is the right layer :-S ) by hardware (msCAN)), thus, if we wanted to have 2 or more 'gateways' to either ethernet, serial etc... it is very possible, however, this is more an application/use of the CAN network, something which the CRICHTON project might be able to use.

Possible Basic Outcomes
Investigate CAN methods etc...., design and implement a simple local clustering/interconnection mechanism allowing basic communication between a number of SPUTNIC 'nodes'.
Included, of course, would be an API allowing other students to use the CAN bus.
Further developments...
Introduction of filters (using msCAN), error handling etc...., support for multiple CAN Buses.
I need to investiage more, but I'm pretty sure it is possible to support 2 or more different CAN buses using different bandwidths/Bit.

A possible demo could be to use the webserver to show specific (simulated) sensor information, though I envisage using a demo like this, I don't see it being a part of the project deliverable.

msCAN - Application Notes

http://www.freescale.com/files/
microcontrollers/doc/app_note/AN2283.pdf
Think this could be a great for the project, basically allows hardware filtering for messages using the message's identifier (similar to how a subnet mask works), thus, hopefully freeing up some of the CPU by not passing unwanted messages, as well as 'maybe' being able to reduce the amount of code actually used to do the software checking of the messages.

NOTE: Would like to try and get the msCAN Filter Generator tool.
This tool helps when deciding what message filters & message identifiers to use. CAN@metrowerks.com

CodeWarrior

MC9S12DP256 Software Development Using Metrowerk's Codewarrior
extern void _Startup();
extern void CAN0_WakeupISR();
extern void CAN0_ReceiveISR();
extern void CAN0_TransmitISR();

PDF http://www.freescale.com/files/
microcontrollers/doc/app_note/AN2216.pdf

Interrupt Priority Scheme

PDF - http://www.freescale.com/files/
microcontrollers/doc/app_note/AN2617.pdf

msCAN Filter Generator

The Motorola msCAN Filter Generator provides a powerful and flexible
way of optimising the filter configuration on an msCAN module. This in
turn can greatly reduce the CPU overhead for handling CAN messages
not intended for a particular node.

Article http://www.freescale.com/files/
microcontrollers/doc/app_note/AN2010.pdf

Dev Board Schematics

http://www.freescale.com/files/soft_dev_tools/
hardware_tools/schematics/MC9S12DP256EVBSCHEM.pdf

CAN is insensitive to Electro-Magnetic Interference (EMI)

Due to the differential nature of transmission, CAN is insensitive to EMI. This effect is caused because both bus lines are affected in the same way which leaves the differential signal unaffected :-)

EMI can be reduced more by using additional shielding, which in addition, reduces the Electro-Magnetic Emissions from the CAN itself.

Bus lengths

The maximum bus length for a CAN network depends on the bit rate used. It is required that the signal has time to travel to the most remote node and back again before the bit is sampled.

Bus length (m)	Maximum bit rate (bit/s)
40	1 Mbit/s
100	500 kbit/s
200	250 kpit/s
500	125 kbit/s
6000	10 kbit/s

ISO 11898 - impedance of the cable 120 +- 12 ohms (twisted par, shielded or unshielded)
Might be hard to find a cable with that impedance for cheap anyway :-S

Standardised Higher-Layer CAN or invent my own?

CANOpen and MicroCANOpen are 2 higher-layer CAN protocols, however, they might be a slight overkill for this project, this needs to be investigated quite a bit probably.
Known advantages:
+With CANOpen, there is a number of tools already supporting the higher-layered protocol
+Can be customised and optimised
Likley disadvantages:
+Probably steep learning curve, though, probably just as much as implementing own drivers etc...
+Probably take up a large amount of memory, though, hopefully could be optimised.

Different CAN Networks Have Different Physical Layer Requirements

CAN, like all major networking protocols, requires a physical layer device in order to communicate. This physical layer comes from the ISO/OSI seven layer stack model. The physical layer is responsible for current and voltage control for the bus, dealing with current and voltage transients, and signalling bus (line) faults and possibly correcting them.

The Bosch CAN specification does not dictate physical layer specifications for anyone implementing a CAN network. This is both a blessing and a curse to the designer. Over the course of the last decade, two major physical layer designs have come to the fore and become the basic physical layer designs used in most CAN applications. They both communicate using a differential voltage on a pair of wires and are commonly referred to as a high-speed and a low-speed physical layer.

The low-speed architecture has the ability to change to a single-wire operating (referenced off ground) when one of the two wires is faulted through a short or open. Although both architectures use a voltage difference on a pair of wires, the termination methods for each are different and incompatible in production systems.

Since there are no requirements on physical layer in the CAN specification, other standards organizations help designers create compatible CAN devices. The International Organization for Standardization (ISO) creates standards to ensure inter-operability of components at the physical layer and recommends design practices. ISO standards are generally followed for industrial applications.

Motorola CAN Features

The basic features of the MSCAN are as follows:
• Modular architecture
• Implementation of the CAN protocol – Version 2.0A/B
– Standard and extended data frames
– 0–8 bytes data length
– Programmable bit rate up to 1 Mbps1
– Support for remote frames
• 4 receive buffers with FIFO storage scheme
• 3 transmit buffers with internal prioritization using a ‘local priority’ concept
• Flexible maskable identifier filter supports two full size extended identifier filters (two 32-bit) or four 16-bit filters or eight 8-bit filters
• Programmable wake-up functionality with integrated low-passfilter
• Programmable loop back mode supports self-test operation
• Programmable listen-only mode for monitoring of CAN bus
• Separate signalling and interrupt capabilities for all CAN receiver and transmitter error states (Warning, Error Passive, Bus-Off)
• Programmable MSCAN clock source either system clock or crystal oscillator output
• Internal timer for time-stamping of received and transmitted messages
• Three low power modes: Sleep, Power Down and MSCAN Enable
• Global initialization of configuration registers

1. Depending on the actual bit timing and the clock jitter of the PLL.

Another CAN Manual Found

BCANPSV2.0/D Bosch Controller Area Network (CAN) Version 2.0 Protocol Standard

MC9S12DP256B Processor

From PDF Microcontrollers SPS Sales Guide:
SG1006/D - Microcontrollers SPS Sales Guide
Page 2
HCS12 Family — Motorola announces the introduction of a high performance 16-Bit MCU Family, starting with 256K memory, and 5 integrated CAN modules — the MC9S12DP256B. This device is the first member of the next generation, high performance HCS12 Family. The entire family is based on new System on-Chip Design Technology (SoCDT), which utilizes the latest synthesized design techniques, to allow faster design, qualification and production of new derivatives, all based on .25 micron technology. Based on the powerful MC9S12 CPU, all family members will be pin compatible and memory upgradeable, with a variety of on-chip peripheral options. This family continues the legacy of Motorola’s best in class 16-Bit MCUs.

Page 15

• RAM 12K Bytes
• FLASH or OTP 256KBytes FLASH
• EEPROM 4KBytes
• Timer 8-CH, 8bit or 4-CH, 16-Bit
• I/O up to 91
• Serial 2SCI / 3SPI / IIC
• MUX 5CAN, It's got CAN :-)
• A/D 2 x 8-CH 16Bit
• PWM 8-CH (Don't know what PWM is though)
• Op. Voltage 5Volts
• Temp. C = -40°C to 85°C, M = -40°C to 125°C, and V = -40°C to 85°C.
  
• Operating Freq. 25.0 MHz
• Manaul : MC9S12DP256/D
  CPU12RM/AD

SPUTNIC_IX - CAN Interconnected Cluster

Description:
SPUTNIC [Single-chip Processor Unit Together with Network Interface Chips] Projects The SPUTNIC Projects are based on the Motorola HCS12 single-chip processor (microcontroller). Three SPUTNIC projects (I, II, and III) were undertaken in 2002/03 and two more (SPUTNIC IV and V) in 2003/04.

Key Objectives:
The SPUTNIC systems include several Controller Area Network (CAN) interfaces - see for example www.interfacebus.com/ Design_Connector_CAN.html - and the purpose of this project is to investigate, design, and implement, a local clustering/interconnection mechanism to allow a number of SPUTNIC 'nodes' to be connected together. It is envisaged that a 'master' node would act as a gateway between an ethernet (TCP/IP) network and the CAN network. This project is likely to involve elements of operating systems, embedded systems, and of course network and communications. One project deliverable is envisaged to be a software library + API to allow other SPUTNIC projects to harness the capabilities of such a local interconnection network.

Hello World

Might as well start this thing off with your typical Hello World