BISS-C Protocol Design

Table of Contents

• Introduction
• System Overview
• Implementation
  • Specifications
  • 3 Channel Peripheral Interface PRU hardware interface
  • BISS-C Firmware Implementation
    • Implementation for Single Channel
    • Firmware Architecture
      • Initialization
      • Receive Position Data
      • Control Communication
      • Post-processing for 16-bit Safety CRC
  • 3 Channel Peripheral Interface
    • Pin Multiplexing
      • LP-AM263P + BP-AM2BLDCSERVO Booster Pack Pin Multiplexing for SDK example

Introduction

This design implements BISS-C Receiver (a.k.a subsequent electronics) using the 3 channel peripheral interface available on the TI Sitara™ processors/microcontrollers. The 3 channel peripheral interface is a digital bidirectional serial interface for position encoders, also suited for safety related applications. Only four signal lines are required, differential pair each for clock and data. In BISS-C, clock is provided by the receiver and data is provided by the encoder. Data is transmitted in synchronism with the clock. Transfer between receiver and encoder at the physical layer is in accordance with RS485, with transceivers at both ends.

System Overview

Position feedback system consists of a position encoder attached to a motor, up to 100 meters of cable which provides power and serial communication and the receiver interface for position encoder. In the case of Sitara™ processor/microcontroller, the receiver interface for position encoder is just one function of a connected drive controller. The Sitara™ processor/microcontroller provides, in addition to the resources for Industrial Ethernet and motor control application, including on-chip ADCs, Delta Sigma demodulator for current measurement. BISS-C Receiver on processor/microcontroller uses one ICSSx Slice. Clock, data transmit, data receive and receive enable signals from PRU of ICSS are available in Sitara™ processor/microcontroller.

Implementation

The BiSS-C receiver function is implemented on TI Sitara™ processors/microcontrollers.

Design is split into three parts:

1. BiSS-C hardware support in PRU using three channel peripheral interface
2. Firmware running in PRU
3. Driver running in Arm®-based core

Application is supposed to use the BiSS-C driver APIs to leverage BiSS-C functionality.

Default SDK examples three channel peripheral interface in PRU0 of PRU-ICSSM.

Specifications

Parameter	Value	Details
Maximum Cable Length	100m	Supports up to 10MHz with delay compensation
Startup/Initialization Frequency	1 MHz	After power on or reset
Frequencies supported	Up to 10 MHz	Changeable at run-time
CRC	6/16 bits	Position-data/control-data verification
Receive oversample ratio	1x to 8x	Tested with 4x, 6x and 8x (Frequency specific)

3 Channel Peripheral Interface PRU hardware interface

Refer to TRM for details

BISS-C Firmware Implementation

Following section describes the firmware implementation of BISS-C receiver on PRU-ICSS. Deterministic behavior of the 32 bit RISC core running up to 200 MHz provides resolution on sampling external signals and generating external signals. It makes use of 3 channel peripheral interface support in PRU for data transmission.

The PRU-ICSS firmware supports the following configuration:

1. Single Channel per PRU slice

Implementation for Single Channel

Single core of PRU-ICSS slice is used in this configuration.

Arm-based core, PRU, BISS-C module Integration for Single Channel

Firmware Architecture

Overall Block Diagram

Firmware first detects and estimates the processing delay of the encoder as part of the initialization. Then it checks the operation mode: host trigger mode, periodic CMP mode, or periodic CAP mode.

Host Trigger Mode: The firmware waits until a command has been triggered through the interface by the host application.

Periodic CMP/CAP Mode: The firmware monitors the configured IEP compare/capture event and sets the host trigger bit when the event occurs, automatically initiating BiSS-C transactions at regular intervals.

Upon detecting trigger, first it checks whether the clock frequency has changed and if yes, it re-estimates the processing delay for the new clock frequency.

Then it reads the position data and checks if a control communication is in process. It verifies the position data CRC by comparing it with the on-the-fly computation of CRC. In case of control communication mode, it backs up the CDS bit and transmits the CDM bit by overriding the clock pulse during the BISS-C cycle timeout phase. If the control communication is in progress it goes back to read the position data for the next cycle. If the control communication is completed, it updates the control command status, position data status and returns to wait for the next trigger from the interface or IEP compare/capture event.

In case the "safety mode" is enabled, firmware will be executed as explained below:

RX flow when Safety is enabled

Firmware will perform configuration as usual and then before entering into RX it checks whether safety is enabled for that particular encoder or not. If enabled, firmware will perform receive and downsample and CRC computation is excluded, after all the encoders data bits are read successfully, before going into timeout firmware will perform post-processing to compute the 16 bit CRC for safety enabled encoders. Please note that post-processing will be applicable only for the encoders for which safety is enabled using control communication. Please find below an image that explains CPW and SPW as per BiSS-C safety specifications.

BiSS Frame according to the BiSS Safety profile

Above image is taken from BiSS Safety Concept Document.

Note

BiSS safety is implemented by assuming 2 encoders connected in Daisy chain, one will send CPW and another one will send SPW. CRC errors are expected while enabling Safety using control communication. Because control communication will need multiple BiSS cycles to confirm and the safety may be enabled in the encoder before control communication is completed and encoder may send 16-bit CRC in some of the BiSS cycles.

Firmware running on PRU-ICSS will remain HALTED if encoder is not detected and application will wait for 5 seconds and exit with error code.

Initialization

Initialization for All Modes

Initialization is performed both on the Arm-based core and PRU as shown in the figure above. During the initialization, based on the clock frequency selected the PRU detects the encoder and estimates its processing delay in terms of clock cycles. The processing delay is measured 8 times and an average value is used for compensation. Note that whenever the user changes the clock frequency, the initialization routine on the PRU is executed to estimate the processing delay.

If using "Multi Channel with encoders of different make" configuration where load share mode is enabled, one of the cores among enabled cores will be set as the primary core for performing global configurations of PRU-ICSS's BISS-C interface. These global configurations include clock frequency configuration and TX global re-initialization.

There needs to be a synchronization between PRUs before changing any global configuration. For this purpose, each active PRU core sets synchronization bit before any operation needing synchronization and clears the synchronization bit when it is ready. The assigned primary core will wait for all active channel's synchronization bits to be cleared and then perform the global configuration.

Receive Position Data

BISS-C main loop for Position Data

Once the firmware receives the trigger from Arm-based core, it will first calculate the RX frame size and check if there is a change in the clock frequency from the previous run. If yes, it will recalculate the processing delay of the encoder for the given clock frequency.

Next, it will start the clock signal to wait for the acknowledgement bit followed by the start bit. If the program is in control mode, it will back up the CDS bit for subsequent processing. Next it will read the position data bits, error and warning bits while computing the CRC on the fly. Finally, it will read the 6-bit CRC. If the program is in control mode, it will override the clock signal to transmit the CDM bit to the encoder.

The program will then wait for the timeout period and verify CRC of the position data bits. If the program is in control mode, it will check if the control command cycle is completed. If yes, it will update the results and the status bits before returning to the starting point.

Control Communication

BISS-C control communication loop

BISS-C control communication is performed over multiple cycles. Refer to the standard for more details on control communication. The firmware expects a control command as a 16-bit hex value. Once a control communication is started, the program will first transmit 14 0's as CDM bit during the timeout period at the end of the BISS-C cycle. This is then followed by a start bit to indicate to the encoder that control communication is in progress. The figure shown above explains the flow for a register read access. The register write access and control commands follow similar steps. Example commands for the register read access are given in the table below.

BISS-C hex commands

Post-processing for 16-bit Safety CRC

BISS-C Safety post-processing for 16-bit Safety CRC

In case safety is enabled, only receive and downsample for the RX bits will be performed first. CRC computation will be performed during timeout in the post-processing section. Processing will be done in loop for all encoders across channels. 16-bit CRC is computed using XOR based approach with the provided polynomial from the BiSS specifications and compared with the received CRC and the error statistics are updated.

Periodic Trigger Modes

The BiSS-C receiver supports two types of periodic trigger modes for continuous position sampling: CMP (Compare) mode and CAP (Capture) mode.

Periodic CMP Mode (Compare Event Mode): In CMP mode, IEP timer compare event triggers position sampling. The firmware monitors the configured IEP compare event and automatically initiates BiSS-C transactions when the IEP timer counter matches the compare value. This enables fixed-rate periodic sampling.

Periodic CAP Mode (Capture Event Mode): In CAP mode, external signals trigger position sampling through IEP capture events. The capture event is triggered on the rising edge of the external input pulse, enabling event-driven position capture. Internal signals can also be mapped to IEP capture events via XBAR. Following is the operation flow for periodic mode:

1. Firmware polls IEP CMP/CAP status register and clears status after event is detected
2. On event detection, firmware initiates BiSS-C transaction
3. Position data is automatically updated in shared memory
4. R5F interrupt notifies application of new data
5. The firmware checks the current trigger mode. If still in periodic mode, it returns to step 1 to wait for the next IEP CMP/CAP event. If the mode has been switched to host trigger mode, the firmware stops periodic operation.

Periodic Trigger Mode

Attention

Input cycle time should be greater than or equal to the BiSS-C cycle time by considering the position data bits, E, W, CRC and timeout.

3 Channel Peripheral Interface

The physical data transmission in 3 channel peripheral interface is done using RS-485 standard. The data is transmitted as differential signals using the RS485 between the 3 channel peripheral interface receiver and the encoder.

The receiver sends the clock to the BISS-C encoder, data transmission in either direction (one at a time) occurs in synchronism with the clock. The design uses two differential signals for each of the lines (clock and data).

BISS-C receiver and the encoder are connected using the RS-485 transceiver. Data is transmitted differentially over RS-485. It has the advantages of high noise immunity and long distance transmission capabilities.

Pin Multiplexing

Attention

Signal Configuration section has details on PRU pin functions in Peripheral IF mode

Note

• k = 0,1 (PRU-ICSS Instance) for AM243x/AM261x and k = 0 for AM263Px
• n = 0,1 (PRU-ICSS Slice)

Pin name	Signal name	Function
PR<k>_PRU<n>_GPO0	pru<n>_bissc0_clk	Channel 0 clock
PR<k>_PRU<n>_GPO2	pru<n>_bissc0_out_en	Channel 0 transmit enable (Fix this pin to low with SoC GPIO mode)
PR<k>_PRU<n>_GPI9	pru<n>_bissc0_in	Channel 0 receive
PR<k>_PRU<n>_GPO3	pru<n>_bissc1_clk	Channel 1 clock
PR<k>_PRU<n>_GPO5	pru<n>_bissc1_out_en	Channel 1 transmit enable (Fix this pin to low with SoC GPIO mode)
PR<k>_PRU<n>_GPI10	pru<n>_bissc1_in	Channel 1 receive
PR<k>_PRU<n>_GPO6	pru<n>_bissc2_clk	Channel 2 clock
PR<k>_PRU<n>_GPO8	pru<n>_bissc2_out_en	Channel 2 transmit enable (Fix this pin to low with SoC GPIO mode)
PR<k>_PRU<n>_GPI11	pru<n>_bissc2_in	Channel 2 receive

LP-AM263P + BP-AM2BLDCSERVO Booster Pack Pin Multiplexing for SDK example

Pin name	Signal name	Function
PR0_PRU0_GPIO3	pru0_bissc1_clk	PRU0 Channel 1 clock
GPIO Pin (PR0_PRU0_GPIO5)	pru0_bissc1_out_en	PRU0 Channel 1 transmit enable (Fix this pin to low with SoC GPIO mode)
PR0_PRU0_GPI10	pru0_bissc1_in	PRU0 Channel 1 receive
GPIO Pin (SDFM0_D1/D13)	ENC1_EN	Enable encoder voltage in Axis 1 of BP (Fix this pin to high with SoC GPIO mode)

Note

Arm is a registered trademark of Arm Limited (or its subsidiaries or affiliates) in the US and/or elsewhere.