Post by thread:[EE] CAN bus information (was CAN on linux)

Hi Luis, > Hi John, > I am just starting with CAN, I am not sure where this is going to take > me, as I am only looking at it because a friend of mine as a > seat for is > car where all the motors and such are controlled by CAN, but I am > finding it very interesting. > I have two questions: > On the ACK slot, is the transmitter expecting any receiver > that is using > that identifier to go Dominant to acknowledge that it as received the > packet? Your misconception is that there is a receiver somehow using the identifier and acting on it in a special way. An easy way to look at what happens to the message transmitted from the receivers perspective is as follows. 1. Receiver baseline engine detects the start bit and parses the incoming bit stream. 2. If more than 5 bits in a row are the same polarity it removes the next bit A) if that bit is not the opposite polarity the engine flags a stuff bit error and issues 6 dominant bits (Error Flag) deliberately creating a stuff error on top of the message which destroys it. B) if the stuff bit is opposite, it's just discarded. 3. All the while the engine is calculating CRC on the unstuffed bit stream. 4. It knows where the transmitted CRC is because it's seen the DLC (data length) and once the CRC is reached A) Verifies it and continues B) Sees it's wrong and creates an error flag destroying the message. 5. Finally the receiver reaches the ACK slot and if everything went well, puts a dominant there; the ACK bit. 6. It finishes ensuring that the rest of the bits of the message aren't dominant and then applies the ID of that received message against the internal filters and masks. 7. Depending on how many Receive object there are, and how many filters and masks the message then either ends up: A) in a receive object in which case an interrupt is flagged B) is discarded. Notice! ALL nodes on the bus will create an ACK. Whether the application ever sees or hears of the message is at a different level within CAN protocol. > If it does not receive an ACK what will it do? On the transmitter side the lack of an ACK will do only one thing. 1. The transmitter will resend immediately after the end of the message. *** The transmitter will _not_ go bus off if an ACK is not received but will retransmit forever. *** The transmitter will increment the Tx Error counter by 8 if another node flags it with an Error Flag. (6 dominant bits). If the error counter reaches 256 because there have been 32 frames destroyed by 32 error flags only then will the node go bus off. > Thanks for the help. > Best regards > Luis > All of the above information is available in more detail in the original BOSCH CAN specification. Regards, John Dammeyer

Hi John, Thank you very much for the detailed information; it is exactly what I was looking for. The bit stuffing part is now clear, because, I understand the reason for the bit stuffing but was unsure about what the node would do with the stuffed bit. The information you provided will also enable me, I think, to find out what I need from the CAN system I am looking at. I am trying to find out what is the specific frame identifier a certain motor controller is "receiving". If I remove all the nodes from the Bus except for the keypad one, and press the button relating to that motor controller, the keypad node, as it will not receive any ACK will continue to send the same frame, and it should be easier to identify. Best regards Luis {Original Message removed}