DigiView Plug-in Guide

The CAN BUS built-in pre-parser is available beginning with DigiView Version 8.1.

 

Extracts all CAN events including Active Error Frames, Overload Frames, Bit Stuffing Errors and Form Errors. Also sends separate events for each field including control bits, delimiters, Extended ID and CRC. Note that framing is inherent in this protocol so the preparser sends the SOF event at the beginning of a frame and will send the End or IDLE event to terminate the frame.

 

Configuration Options provided by the pre-processor

Data Channel
Selects which physical channel to capture and decode.

Bit Rate/Duration & Scale:

Specify a value for the Bit Rate or the Bit Duration, then select a scale for the value entered. Scale selections include Nano seconds (ns), Micro seconds (us), Milli seconds (ms), Baud, KiloBaud (KBaud) and MegaBaud (MBaud).  Note that the value must be an integer (no floating point.)  To specify something with a decimal point, select the next lowest range and enter a whole number.  For example, 115.2 KBaud would be entered as 115200 Baud and 12.31us would be entered as 12310ns.

 

Sample Point (%bit)

Specifies where we should sample the data within each bit cell as a percentage of the bit width. This defaults to mid-bit (50%) and can be adjusted to account for bus propagation delays, transceiver delays, bandwidth limitations, etc.  This roughly corresponds to the combined settings of the SYNC_SEG, PROP_SEG and PHASE_SEG_1 mentioned in the CAN specification.  Alternatively, it could be viewed as the total bit width - PHASE_SEG_2.

 

Sync Jump Width (%bit)

Specifies the percentage of a bit width to allow for resynchronization adjustments. This corresponds to the SJW parameter in the CAN specification.

The CAN specification allows for a wide tolerance on node oscillators.  This is accomplished by requiring that nodes resynchronize on passive->dominate edges.  The receivers compare the actual timing of these edges with the ideal timing at the specified baud rate and then make adjustments to their internal timers to resynchronize with the incoming data.  This parameter specifies the maximum adjustment we will make when resynchronizing.

Increasing this number increases our ability to properly decode packets involving nodes with low accuracy oscillators at the expense of increased noise sensitivity.  Lower numbers improve noise rejection but reduces our ability to work with nodes with low accuracy oscillators.  You usually set this lower if all nodes use crystal oscillators for their baud rate reference, and higher if any of them use ceramic resonators or other low accuracy sources for their baud rate references.

Be aware that the (SAMPLE-POINT + SJW) should be less than 100% and that (SAMPLE-POINT - SJW) should be greater than 0.

 

Filter Glitches <= (%bit)

Specifies filtering of pulses that are less than or equal to the specified percentage of the Bit width. DigiView has a much higher bandwidth than most CAN receivers so it is capable of capturing glitches or noise pulses that normal receivers might not even see.  Also, many CAN receivers have different levels of filtering available. This option lets you tell us how relatively good we should be at rejecting noise pulses.  A setting of 0 tells us to process full bandwidth data with poor rejection.  Increasing this setting makes us simulate higher immunity parts. Selection range is from 0% to 10%.

Events

The built-in CAN preparser generates 25 Event Types which are identified in byte[7]. If an error occurs or an invalid value is detected, byte[6] will be non-zero. Bytes[5:0] can contain up to 48 bits of data. The content of Data will depend on the event.

Event Format:

Byte[7]        =        Event Type

Byte[6]        =        Flags - (see the Event Type tables for flags supported by each event)

Form Error                (bit 0 : 0x01)

Invalid Value                (bit 1 : 0x02)

Bit Stuffing Error        (bit 2 : 0x04)

 

Bytes[5:0]        =        Data - Contains up to 48 bits of data. Contents will be one of the following based on the event:

 

1. Field Value - Will contain the value of the field event.

Applicable Events: Base ID, EXTID, DLC, CRC

 

2. Bit Count - For multi-bit events that have no relevant data. Will contain the number of successive bits denoting the event. If the number of bits or state (Dominate or Recessive) is incorrect, the Form Error flag is set in Byte[6].

Applicable Events: EOF, EF-D, OL-D, OVERLOAD, ERROR, END, IDLE, IFS-I, BITSTUFF

 

3. Bit state - Denotes the state of single bit field events. 0 = Dominate,  1 = Recessive. If the state is wrong for the event type, the Form Error flag is set in Byte[6] for appropriate events.

Applicable Events: SOF, SRR, RTR, IDE, R1, R0, CRC-D, ACK, NAK, ACK-D

 

Field Event Types - Byte [7] =

Use StartField() to format Field event types. EndField() is not required as any field will automatically terminate when the next StartField(), StartFrame() or EndFrame() is called or when the end of data is reached. If a form error occurs, the Error flag will be set for applicable events.

 

Note: Each event is sent in chronological order and already has a unique Timestamp. If adding your own field by splitting events into multiple StartField() calls, do not use a previous or duplicate time stamp or one that is greater than the event's timestamp. Make certain each field's timestamp is (> last) and (<= current).

 

Frame Event Types - Byte [7] =

Use StartFrame() or EndFrame() accordingly. If an error occurred, the Error flag will be set for applicable events. Events IFS-I and BITSTUFF are always an error.

Note: The IDLE event is almost equivalent to the END event. Both events indicate a termination of the frame but under different circumstances. In either event, if you want to see the "idle" period between frames, use the EndFrame() routine to terminate it. This is not a requirement since all frames automatically terminate when a new frame begins or the end of data is reached.