CAN Bus ACKERR regıster

[Besir]

Hı,

I'm using MCF52235 can bus protocol for communication

I send message from transmitter device to receiver device . I get the message from the transmitter device but I want to know the message that I have send have been transmitted or not.

For this, I read ACKERR regıster , 

ACKERR :

Acknowledge error. Indicates whether an acknowledgment has been correctly received for a transmitted message.

         0 No ACK error was detected since the last read of this register.

         1 An ACK error was detected since the last read of this register

When I remove the receiver device from the can bus network , ACKERR regıster  don't change .(always 0)

How can I know that my message has been sent or not. (may be a different method )

is anyone can help me? 

[TomE]

Read everything you can on the CAN bus. Start on the Wikipedia page and follow all references.

CAN bus messages are "reliable". Every device on the CAN bus validates every transmitted message. The ones that receive the message properly (no bit errors and the CRC is OK) will set the ACK bit so the transmitter knows at least one got it OK. Any that detect errors will respond with an ERROR indication. So if there's an ACK and no ERROR then the message got sent OK.

As well as that, the CAN Protocol requires the transmitter to keep retrying until the message gets through, or until a "transmit error counter" counts up to a limiting value. So if you get a transmit interrupt without an error interrupt the message was sent on the wire properly and at least one device saw it was OK. That doesn't guarantee that all devices received it OK. They may be out of buffers or have buggy code in them or whatever.

> ACKERR regıster  don't change .(always 0)

So you're not getting any transmit errors.

If you want to truly guarantee a message was sent then the receiver has to send back some sort of reply message. It isn't a CAN bus problem. If you want "guaranteed reliable data delivery" then you have to build a reliable protocol on top of that one.

But the CAN bus is usually good enough (once all the software has been debugged and tested" that it doesn't need that sort of feedback. It isn't like the Internet (or even an office Ethernet).

A good way to use the CAN bus (sort of what it was designed for) is to consider it like "shared memory". The messages correspond to related collections of "shared variables".

As an example, imagine a network made up of 5 controllers:

1 - Controller monitoring the headlight switch,

2 - Instrument Cluster,

3 - Controller under the bonnet driving the front lighting clusters,

4 - Controller in the trunk driving the rear lighting clusters.

All devices are on a shared CAN bus and all have a variable called "park lights".

Device (1) reads the physical headlight switch and sets the "park lights" variable in its memory accordingly.

All other controllers monitor the "park lights" variable in their memories and make the park, tail lights and instrument cluster illumination follow the state of that variable.

The advantage is that code like that works if all the code is in the one central "body controller" box or distributed in different boxes throughout the car - it doesn't matter.

The CAN controller in Device (1) periodically transmits that variable in a CAN "lighting" message (possibly together with the headlights, foglights and turn-indicator variables).

The CAN controllers in devices (2), (3) and (4) copy the bits from the "lighting" message into their local variables, including the "park lights" one.

That's it. That's a car. Make the protocol more complicated than that at your peril. :smileyhappy:

Tom

[Besir]

Hı Tom,

Thanks for your suggestions. 

I understand that I must  use a protocol , for guarante the messages that  have been send from transmitter to receiver.

thanks.