Controller Area Network Interconnected Cluster

Report Finished!

2006-04-17T15:33:00.000+01:00

Deserves a few beers I think ;-)

Mask Set Errata

2005-11-04T19:33:00.000Z

http://www.freescale.com/files/
microcontrollers/doc/errata/MSE9S12DP256B_1K79X.pdf

There is a few things in here about the CAN and other relating issues

Sputnic Project Group Meeting - Minutes

2005-11-03T11:58:00.000Z

Agenda:
1. Project Labs
2. Licences
3. Mailing List
4. Poster Presentation
5. Cross-over of projects
6. Resources / Shipping List

1. Project Labs
5th year MEng students have already been assigned a lab within the Royal College building. Room R169.

Honours Students will be assigned some PCs within the Arrol Lab (L1009).
This is yet to happen, however, the process of getting these systems is underway.
There might have to be some sort of booking system put in place for these machines.
There might be the need for a hardware lab as well. Students would use this lab for implementing any addition hardware.

2. Licences
The 5th year students will need a licence for their R169 project lab.
System support are going to install the licences onto PCs in the arrol lab and hopefully they will have this sorted out by the end of next week.
Furthermore, we will hopefully be able to get licences for our home machines, however, to have a fully functional home machine will depend on the amount of BDMs available.

3. Mailing List
A mailing list has been set up as sputnic@cis.strath.ac.uk, however, it is not fully active yet. You will recieve an email once you have been subscribed to it.
In addition to the mailing list, a wiki (tikiwiki) has been set up.
Http://www.cis.strath.ac.uk/local/wiki

We are encouraged to use this to this wiki to share common information about the Sputnic projects.

4. Poster Presentation
Week 11 - 6 x A4 (landscape)
As advised by the 5th year students, the use of a Gant chart is recommended.
The Poster Presentations will be cover in more depth at another time.

5. Cross over of projects
Please collaborate individually with each other on relevant material.
Furthermore, the wiki is in place to help with common issues/problems.

6. Resources / Shopping List
There is a limited number of BDMs; we need to check out exactly how many, however, need a full Licenced machine to do that.
Furthermore, the black boxes need to be checked and marked with working or not working. After which, we can take steps to getting them fixed.
Duncan is going to hopefully tap Freescale for some more free stuff, hopefully some more BDMs as well and other things students need.
Each student has to create an invidual shopping list of parts they need and email them to duncan, e.g. Zigbee chips, ethernet etc....

Other Information.
All emails regarding the projects should have the prefix [project]
As advised by Duncan, it is recommened to have some sort of contingency plan, please try and simulate something incase the actual hardware is not available or you start to have issues with it.

To dos:
Email Duncan your shopping list (remember the [project] prefix)
Email Duncan your preferred times for individual meetings and also whether you prefer them on a weekly or 2 weekly basis, please remember Duncan would prefer Mondays, Thursday & Fridays if possible and again, the [project] prefix.

Statement of Intent

2005-10-30T00:41:00.000+01:00

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)

2005-10-27T10:30:00.000+01:00

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

2005-10-24T13:10:00.000+01:00

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

2005-10-24T13:02:00.000+01:00

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...

2005-10-24T10:44:00.000+01:00

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

Bit Timing

2005-10-17T23:08:00.000+01:00

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

33388 FAULT TOLERANT CAN INTERFACE

2005-10-17T22:00:00.000+01:00

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)

2005-10-16T16:33:00.000+01:00

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

2005-10-15T21:07:00.000+01:00

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

MSCAN on the MC9S12DP256 compared with HC12 family

2005-10-15T21:06:00.000+01:00

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

Error Detection

2005-10-15T20:54:00.000+01:00

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

MSCAN Wake-up

2005-10-15T21:01:00.000+01:00

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

Resets and Interrupts

2005-10-15T20:42:00.000+01:00

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

2005-10-15T20:40:00.000+01:00

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

2005-10-15T19:58:00.000+01:00

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

Memory Map

2005-10-15T19:56:00.000+01:00

$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

2005-10-15T19:38:00.000+01:00

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

2005-10-14T11:01:00.000+01:00

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

2005-10-13T20:47:00.000+01:00

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

Interrupt Priority Scheme

2005-10-12T23:49:00.000+01:00

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

msCAN Filter Generator

2005-10-12T23:32:00.000+01:00

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

2005-10-12T23:25:00.000+01:00

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