Sharing | CRC&E2E Checksum Methods for TSMaster CAN and CAN FD

For users who have switched toolchains and are not particularly familiar with CRC/E2E checksum processing in bus communications on TSMaster, this article can assist customers in quickly completing CRC/E2E checksums for CAN/CAN FD bus communications using TSMaster.

Keywords: TSMaster, CAN/CAN FD, CRC Checksum, E2E Checksum

Table of Contents for this article

1. Application of CRC/E2E in the message transmission process

Typical application: CAN/CAN FD message transmission between two CAN nodes (ECUs), the two sides stipulate that the message (0xC9:ABSdata) Byte0-Byte6 need to carry out CRC checksum verification, the high four bits of Byte6 are RollingCounter, and the checksum result is put into Byte7.

Therefore, for the node that sends this frame to the DBC, it needs to increment the RollingCounter value of each frame before sending it to the bus, then perform CRC checksums to put the checksum value into Byte7, and finally send the frame to the bus; for the node that receives this frame from the DBC, it needs to perform CRC checksums to compare the checksum result with the data in Byte7, otherwise, the data is discarded. For DBC to receive this frame, it needs to perform CRC check on this frame and compare the result with the data in Byte7, if the result is the same, then the data in this frame is valid, otherwise the data will be discarded.

E2E (End to End), the standard defined by Autosar, includes CRC algorithm, requires how to increment the value of Counter, and records the corresponding error status when Counter is wrong, etc. From the perspective of sending node, it can be simply understood as filling Checksum and Counter before sending. From the sending node, it can be simply understood as filling the Checksum and Counter values before sending, and the basic operation is the same as CRC.

2. CRC checksum based on TSMaster residual bus simulation

Based on the remaining bus simulation CRC checksum, this method can be done in TSMaster simulation-CAN bus simulation, no code is needed, but the CRC checksum algorithm is the general CRC algorithm, such as CRC8, CRC16, CRC32, etc. Before using it, you need to load the database file in the project and bind the corresponding application channel. Before using, you need to load the database file in the project and bind the corresponding application channel.

Next, turn on the CAN bus emulation and activate all signals of the telegram as well as the node and network where they are located (here 0xC9 ABSdata as an example):

From here we can see that the signal types of ABS_RC and ABS_CheckSum are still common signals, so how to realize the self-increment cycle of RC and the calculation of CheckSum by 0 code? The specific implementation has been realized in the bus simulation module, users only need to make relevant settings in the interface to realize, the following are the detailed steps.

1) Right click on ABS_RC and select Set as Rolling Counter Signal (RC), when finished you can see that the signal type has changed to RC.

The range of RC value self-increment can be set directly in this module. Right-click anywhere in the CAN bus simulation tree window to open the edit RC value range, then check the signal, manually enter the maximum and minimum values of RC, and confirm to save.

2) Right click ABS_CheckSum, select Set as Checksum Checksum Signal (CRC), then the default algorithm library will be popped up, here to select crc8 example. After finishing, the type of the signal has been changed to CRC(crc.crc8[0:7]), which means that the signal is a CRC check signal, and the check algorithm is crc8 in the crc library, and the protection bytes are 0-7:

If the user needs to modify the byte range of the checksum, the same as the RC value range, open the Edit CRC Algorithm parameter by right clicking in the window; the start of the protection byte and the number of protection bytes can be edited in this window.

At the same time the window can be unified for all the CRC signal editing, double-click on the signal where the CRC algorithm column can open the algorithm selection window, if the user's algorithm is not the standard CRC algorithm, we can also go to the crc library to add a custom function, so that can also be identified for the use of this module for the remainder of the bus emulation, the prerequisite to note is that the interface of custom algorithms Note that the prerequisite is that the interface of the custom algorithm must be the same as the existing one, that is, the parameters of the function must be (pu8 data, s32 datalen), so that it can be used normally.

Another use scenario, the need to check the data content in the head/tail of the data to add a fixed byte of data, it is not difficult to find in the CRC algorithm parameter editing window has also done the interface processing, the user can add data directly in the box, multiple data can be separated by the English symbol (,).

The above is based on the configuration of the bus emulation CRC checksum procedure, after the completion of the bus emulation can be run in the message information window to see the message sent.

3、CRC checksums supported by TSMaster localization

This method is suitable for the case that the CRC check algorithm is different from the algorithm function interface in the crc library, and it is also necessary to utilize other information of the message frame for checking, for example, the message ID is also used for checking calculation. In this case, you can use the applet in TSMaster to complete, this project takes C applet as an example, Python applet is the same.

Before the demo, the database will be loaded, as mentioned in the beginning, the CRC checksum is simply said to fill the RC and CheckSum checksum values into the message data, at this time, the user can modify the RC and CheckSum values by pre-sending the event in the applet.

After you have finished editing the content, you need to run the applet and then either send a message in the Message Sending window or start the CAN residual bus emulation (in this case, you need to set RC and CheckSum to the normal signals, so that these two signals are only controlled by the applet).