Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Comments on CAN bus open circuit detection

Parent

CAN bus open circuit detection

+2
−0

I have a PIC18 and I'm trying to detect whether it is connected on the CAN bus or not.

When the PIC is not connected on the bus, and I load the transmit buffers, after setting the TXREQ flag. The transmission does not start. This is also mentioned in the datasheet:

Setting the TXREQ bit does not initiate a message transmission.

However I cannot find a reliable way to detect that the PIC is not plugged into a healthy bus.

Also, no errors in the registers appear.

The only thing I can think of is polling the TXREQ flag for a few milliseconds to check if the peripheral initiated a transmission or not.

But I'm not sure if that is a reliable algorithm. If yes, how much should that timeout be? 1ms or 100ms?

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

Heartbeat message on the CAN bus (2 comments)
Post
+2
−0

There is no direct way to determine whether the PIC is connected to a CAN bus. Part of the problem is that the PIC never directly connected to the CAN bus anyway. There is a transceiver chip like the MCP2551 between the PIC and the bus. The PIC interfaces to the transceiver via two digital signals: CANTX and CANRX.

CANRX indicates the state of the bus, whether it is in recessive (idle) or dominant state. Since it is a digital signal, you only get one of those two indications. There is no way to signal not connected.

CANTX allows the PIC to either drive the bus to the dominant state or leave it alone. Again, it's a digital signal, so you only get those two choices.

The signal levels on the CAN bus itself (CANH and CANL lines) are quite different from digital logic signals. The two lines are passively pulled together by a total of 60 Ω when everything is connected correctly. There is also circuitry in the driver chips to float these signals at a nominal 2.5 V. To signal the dominant state, CANH is pulled high by 900 mV, and CANL low by 900 mV. To "read" the bus, you decide whether the signals are at the same level, or 1.8 V apart. That makes the bus differential, with good common mode noise immunity.

The MCP2551 weakly holds both CAN lines together, so they float at the same voltage when nothing is connected to the CANH and CANL pins. The PIC therefore sees no difference between a bus in the idle state, and no bus connected.

To truly check whether a valid CAN bus is connected to CANH and CANL, you would have to look at their analog levels and test their impedance. This would take additional hardware, and could also interfere with bus operation when there is a real bus connected.

About the best you can do from the PIC without additional hardware is see whether messages are sent successfully. For a message to be sent, there has to no only be a bus connected, but there has to be at least one other node on the bus to respond with ACK to the message. If the PIC sends a message and receives no ACK, then it retries automatically. I don't remember if it gives up after some number of retries to avoid polluting the bus, but either way, this is something you should be able to detect.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

I think it doesn't give up and it is constantly trying to transmit the message. That was the real pro... (3 comments)
I think it doesn't give up and it is constantly trying to transmit the message. That was the real pro...
DeadMouse‭ wrote 5 months ago · edited 5 months ago

I think it doesn't give up and it is constantly trying to transmit the message. That was the real problem. I need to implement a custom timeout but I have no idea how much should that timeout be.

Lundin‭ wrote 5 months ago

When a CAN controller fails to send, it automatically tries again. It will increase an error counter and after failing a number of times go "error passive", meaning it can no longer send error frames driving the bus to the dominant state. If the error counter keeps increasing it will eventually go "bus off" and just disconnect itself from the bus. The CAN controller inside the PIC may or may have corresponding error flags to these states, or allow you to read the error counters. All of this behavior is as per the CAN standard and not specific to a certain part.

DeadMouse‭ wrote 5 months ago

I tried polling the error counters. I didn't see anything increasing. All that while PIC was not connected with another node.