Calculation of CRC for CAN Network

[maskar]

In part of my testing using an external gateway, I would like to change the value of a signal and send the message back onto the bus, with the correct CRC.  I would need to calculate the CRC specific to the CAN protocol, and was just wondering how that differs from other CRC calcs.  From what I've read so far, it's just that there is a 15 bit CRC with a generator polynomial.  Am I missing anything else here?

[Hooovahh · Accepted solution]

---

@maskar wrote:

 Am I missing anything else here?

---

Maybe, I think we would need more information to be clear.  But as far as CRCs go, there are two I'm familiar with as far as CAN...

First the transceiver handles the CRC itself, and is something you don't need to bother with.  It is there to ensure that the message came in without error, and generally a messages that has a wrong CRC isn't even seen, and is just resent until it comes in properly.  I can't remember but I think the XNet API will allow you to know when a CRC has failed, but I don't think a frame read, will return a frame that had a CRC that was incorrect.  And again this isn't something you can change.  When you write the 8 bytes of a CAN payload, the hardware takes care of the CRC and it is part of the message outside of those 8 bytes.  More here on the bits going out.

The other type of CRC I'm familiar with is in addition to this one and is part of the 8 bytes of the payload.  I've seen times when a DBC is designed so that the first 7 bytes of data have some useful signals in it, and the 8th byte is the CRC of the previous 7.  Every time I've seen this used the CRC algorithm has been the same one, some times named CRC-8-SAE J1850.  This uses polynomial 0x1D, I've heard of others being used but personally this is the only CRC type I've used within the 8 bytes of the payload.  When this is used, anytime data in the 7 bytes changes, then the CRC must be recalculated, and sent out.  XNet hardware has a non-documented feature that allows for the hardware to handle this for you.  There is an idea on the Idea Exchange to make this an official feature.  Until then you can read up on the official way NI would recommend doing this, which is using the Frame Out Queued method mentioned in Part 9 of my CAN blog.  While the undocumented method of having the XNet hardware do it for you is in Part 10 of my CAN blog.

[maskar]

Thank you for that explanation.  I was a bit confused as to which CRC I had to calculate, the Bosch document on the CAN protocol only seems to describe the generator polynomial for the CRC-15.

I did find some C source code for calculating the CRC-8 SAE J1850, which I have ported into CAPL (for Vector hardware), and things are working fine so far.

Thanks again!

[pmanieee]

hi, 

i tried with capl code which i was modified from c code. its not working for me. can you post your capl code.