Keywords: TSMaster, CAN/CANFD, CRC Checksum, E2E Checksum
Table of Contents for this article
1. Application of CRC/E2E in the message transmission process
Typical application: CAN/CANFD 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
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.
- 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.
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.