In the last blog, we have covered the basics of CAN communication. Now, we will see about some of the advanced concepts involved such as Bit Stuffing, frame types, error types, Synchronization etc. We will also look into some of the non-standard extensions available in modern CAN controllers.

Generally, all CAN modules support the classical CAN protocol. It can receive and transmit both CAN base and the CAN extended frames. The transmission and reception of CAN FD frames is optional. Classical CAN Implementation do not support 29-bit identifiers. CAN 2.0B passive nodes were compliant with ISO 11898-1:2003, but it used very rarely. In this context, let us explore some of other concepts in detail.

Bit Stuffing

Bit Stuffing is used to ensure the synchronization of all nodes even when transmitting consecutive information with same value either 1 or 0.
During the transmission of message, a maximum of five consecutive bits may have the same polarity. In this case, the transmitter will insert the one additional bit of opposite polarity into the bit stream before transmitting the further bits. This will ensure that there is always some activity in the bus with in 6-bit intervals and hence avoid DC Voltage build up as well as being in sync with the transmitter.

Stuffing and De-stuffing

On the receiving end, similarly the receiver also checks the number of bits of same polarity and removes the stuffed bits again from the bit stream in a process called de-stuffing.

CAN Frame Types

There are 5 types of frames in CAN protocol;

Data Frame (DF):

Carries Data from transmitting node to receiving node.

Remote Frame (RF):

Some times, a node might want to request some data from another which is made possible by Remote frame.
There are two differences between data and Remote frames.
RTR field of a data frame is dominant and RTR field of remote frame is recessive.
In data frame format data field is present, whereas in Remote frame format data field is absent.

The receiver will understand that transmitter is requesting some date and then prepares and sends the Data frame based on the protocol.

Error Frame (EF):

This type of frame is transmitted by any node to signal error.
The error frame consists of two different fields in CAN.
superposition of ERROR FLAGS (6–12 dominant/recessive bits)
ERROR DELIMITER (8 recessive bits).
There are two types of error flags:

Active Error Flag

When the Transmitting node transmitted six dominant bits, the error will be detected in network and the error sate called active error flag.

Passive Error Flag

When the Transmitting node transmitted six recessive bits, the error will be detected in network and the error sate called passive error flag.

Now let us see, how the CAN manages error states. In every CAN node, there are 2 error counters – Transmit Error Counter (TEC) and Receive Error Counter (REC). When the transmitter detects an error in the transmitted frame, it increments the TEC by 8. A receiver detecting an error will increment its REC by 1. On successful transmission/reception the error counters are reduced by 1.
Based on the error counts, the node behavior varies.

  • By default, the Active Error frame will be transmitted on the bus, when TEC and REC < 128. Thus, it will invalidate the frame globally.
  • But when 127 < TEC \ REC > 255, the passive Error frame will be transmitted on the bus, without affecting the bus traffic.
  • Finally, the node enters into the Bus off state, when TEC > 255. If node enters into the bus off state then no frames will be transmitted.

In any case, both transmitter and receiver reject the erroneous frames completely and do not process it any further.

Overload Frame (OF):

Overload frame contains two fields such as Overload flag and Overload Delimiter.
The over load frame will be generated, when the receiving node is overloaded – i.e. it is not able to detect and receive the incoming messages. The format is very similar to Error Frame but without the error counters incrementing. An Overload frame indicates that its transmitter require delay before receiving next data or remote frame and is mostly not used in modern CAN controllers.

Inter Frame Space (IFS):

Data frames and remote frames are separated from preceding frames and succeeding frame by a bit field called interframe space. It consists of three consecutive recessive bits. Following that, if a dominant bit is detected, it will be regarded as the “Start of frame” bit of the next frame.

Frame on CAN BUS

Error Types

There are 5 types of error in CAN protocol.

Bit error:

Every node reads back, bit by bit from the bus during transmitting the message and then compares the transmitted bit value with received bit value. If bit received does not match with bit sent, then Bit error is said to be occurred.

Stuff error:

Set when more than five consecutive bits of same polarity are received in receiving node.

CRC error:

A transmitted always transmits the CRC value in the CRC field of CAN frame. The receiving node also calculates the CRC value using same formula and compares with received CRC value. If receiving node detects mismatch between calculated CRC values and received CRC value then it is called CRC error.

ACK error:

Occurs when no acknowledgment is sent by receiving node or no acknowledgment received in transmitting node.

Form error:

Set when fixed format fields in receive frame is violated. No dominant bits are allowed in CRC delimiter, ACK delimiter, EOF and IFS.

Synchronization and Re-synchronization

As there is no separate clock signal on the CAN bus, the node itself need to synchronize on the bus. For that reason, the underlying transmission format is NRZ-5 coding.
When the transmitting node sends CAN frame it consists the first bit of SOF (start of frame). All the receivers align themselves to this falling edge (recessive to dominant) after the period of bus idle. This mechanism is called hard synchronization.
After subsequent falling edges on the CAN frame are used to re-synchronize the nodes on bus and it is called soft synchronization. This resynchronization happens continuously at every falling edge (recessive to dominant transition) to ensure transmitting and receiving nodes stay in sync.

Additional functions

Some CAN protocol implementations offer optional functions that may or may not be a part of CAN specification. These include, for example, the single-shot transmission of data frames. This means that the automatic re-transmission in case of detected errors is disabled. This is useful for TTCAN add-ons and some tool applications.
Another option generally available is the bus-monitoring mode. The node can receive data and remote frames, but doesn’t acknowledge them and also doesn’t send error and overload flags. Nevertheless, these dominant bits are communicated internally in the CAN module.
In another optional restricted operation mode, the CAN module behaves equally, but it acknowledges received data and remote frames. The error counters are not incremented and decremented in this mode. If a node is the TTCAN time master, it must be able to transmit the time-reference message; other frames must not be transmitted.
For some applications, message time stamping is required. ISO 11898-1:2015 specifies that the optional time-stamp function features resolutions of 8-bit, 16-bit, or 32-bit. The time-base value is captured at the reference point of each data frame and it is readable after EOF (end-of-frame). Other (not standardized) optional functions include readable error counters, configurable warning limits, interrupt request generation, and arbitration lost capture.
If the CAN implementation allows changing the configuration of a node by software, the configuration data (e.g. bit-time configuration or operating mode) needs to be locked against changes while CAN communication is ongoing.

Armed with details of CAN communication, we will now attempt to understand general configuration of a CAN node for transmission and reception with examples from a real controller.

About Embien

Embien Technologies is a leading provider of product engineering services for the Automotive, Semi-conductor, Industrial, Consumer and Health Care segments. Working with OEMs in Industrial segments, we have developed numerous gateways, sensory modes on top of CAN network and protocols such as DeviceNet, CANOpen etc. Our Automotive experience enabled us develop Telematic units and In-vehicle Infotainment systems, Instrument clusters with CAN interfaces.

This blog demonstrates the Windows Embedded Compact 7 on NXPs iMX6 UltraLite evaluation kit with the video as a proof of Embien’s capability in porting WinCE 7 operating system on various processors and architectures.

The EVK includes an LCD display, audio playback and many connectivity options. It is designed to showcase the most commonly used features of iMX6UL processor in a small, low cost package and to facilitate software development with the ultimate goal of faster time to market.

Below is the video demonstration of the OS running on NXPs iMX6UL evaluation kit.

About Embien:

Embien Technologies is a leading service provider in the Embedded software domain. Our team has rich experience in working with various OS like Linux, Android, Windows CE, FreeRTOS, uC-OS, QNX etc. We have created various applications on top the WinCE systems such as HMI, Medical instrumentation displays, Smart Home control system etc. We have also enabled running legacy Windows Applications on top of latest hardware and software including emulation over Linux using technologies such as Mono, OpenNETCF etc.

Windows Embedded Compact 7 is a popular OS being used in low power embedded systems. Embien, working from its early iterations from 4.2 to latest 2013, has ported the same on to NXP’s iMx 6UL based development platforms. This blog demonstrates the Windows Embedded Compact 7 on iMx6 UltraLite with the video, show-casing our capability in porting such Operating systems to various processors and architectures.

Windows Embedded Compact 7

Windows Embedded Compact 7 more commonly known as WinCE 7 or WEC7 is the successor to the WinCE 6.0. Released on 2011, it is still one of the most popular versions of the Microsoft offerings for the embedded devices.

Some of the features of the OS include

  • Rich User Interface
  • Silverlight support
  • Support for Symmetric Multi processing (SMP)
  • Rich Media play back support
  • Complete Win95 based shell

In a WEC7, is still more sought after than its successor WEC2013 because of better licensing options and more importantly the availability of the Shell. From WEC2013, Microsoft removed the support for Windows 95 like Shell that forces the developer to offer an equivalent shell which involves a lot of effort. Further WEC 7 can be ported on the non-Thumb2 only devices too.

WinCE on NXP iMx6UL

Embien offers its expertise in Windows CE for porting the RTOS on to various platforms. One of the most popular low cost SoC of recent times from NXP stables is the iMx6UL. This processor has gained a good market share at low power low cost computing. Some of the features include

  • ARM® Cortex®-A7 @ 696 MHz, 128 KB L2 cache
  • Parallel LCD Display up to WXGA (1366×768)
  • 8/10/16/24-bit Parallel Camera Sensor Interface
  • 16-bit LP-DDR2, DDR3/DDR3L
  • 8/16-bit Parallel NOR FLASH / PSRAM
  • Dual-channel Quad-SPI NOR FLASH
  • 8-bit Raw NAND FLASH with 40-bit ECC
  • 2x MMC 4.5/SD 3.0/SDIO Port
  • 2x USB 2.0 OTG, HS/FS, Device or Host with PHY
  • Audio Interfaces include 3x I2S/SAI, S/PDIF Tx/Rx
  • 2x 10/100 Ethernet with IEEE 1588
  • 2x 12-bit ADC, up to 10 input channel total, with resistive touch controller (4-wire/5-wire)
  • Advanced Power Management
  • Partial PMU Integration

Many vendors offers different development boards for the same. Some of the popular platforms are

  • NXP – iMX 6 UltraLite EVK
  • Variscite – DART-6UL
  • Compu lab – SOM-iMX6UL
  • TechNexion’s PICO-IMX6 COM
  • iWave Systems – iW-RainboW-G18M-SM
  • Embedded Artists – iMX6 UltraLite COM Board

Embien has ported Windows Embedded Compact 7 (WEC7) on to the NXP iMx6UL supporting all the major peripherals. Below is a video demonstration of the port running on the Variscite DART-6UL platform.

 

A video of WEC7 running on NXP iMx6UL Platform.

About Embien: Embien Technologies is a leading service provider in the Embedded software domain. Our team has rich experience in working with various OS like Linux, Android, Windows CE, FreeRTOS, uC-OS, QNX etc. We have created various applications on top the WinCE systems such as HMI, Medical instrumentation displays, Smart Home control system etc. We have also enabled running legacy Windows Applications on top of latest hardware and software including emulation over Linux using technologies such as Mono, OpenNETCF etc.