TCAN334: Node works alone on CAN bus with PCAN adapter but when on a full network device stops receiving ACK bits after some time.

Hi Daniel,

Thanks for your reaching out on E2E.

This question seems to be related to CAN controller, not CAN transceiver. The CAN transceiver does not have the ability to detect a blocking mode and stop transmitting/receiving messages, it also doesn't care what message is being transmitted/received. It's simply interrupting the digital input into a differential signal on CAN bus, and vice versa. It is possible the CAN controller received too many error bits so it stopped communicating. 

When this situation happened, was the TCAN334 working in normal mode (S pin pulled down)? 

Regards,

Sean

Sean, 

Thanks for the response. 

And yes, it makes sense this is connected to the controller. 

When you talk about error bits are you referring to the internal error counters such as the RX and TX counters? When we see the connection problems the transmit error counter goes to 128 and the device enters a passive error state. There is no ramp up time to the error counter, it happens all at once as if the physical connection was lost. We have thoroughly tested the physical connection. Simply disconnecting the CAN software (we are using PCAN-view) and reconnecting it will resume normal behavior on the device. 

Also, yes, the S pin is pulled down. 

Do you have any thoughts on my question about the RX FIFO? Is it possible for a full RX FIFO to adversely impact other CAN behavior? 

Thank you

Hi Daniel,

When an error occurs, the devices that experience the error are expected to transmit an error frame onto the bus. Ironically, if that node has a transmission issue, then it would cause it to experience another error. These can stack up until the error count reaches 128, at which point it continues to participate but doesn't actively interrupt when it detects errors (passive error state). If the error count continues to increment and reaches 256, the controller shuts down and enters "bus-off" where communication is completely halted for the node. This can take multiple seconds to happen, or "at once" depending on the communication rate and bus load you're using. Other than ACK error, did you see any abnormal CAN waveforms? Please include the TXD/RXD and CANH/L waveforms if you believe so.

For you question, please contact your MCU supplier as this is not handled by CAN transceiver. If you are using MCAN in case a message is received while the corresponding Rx FIFO is full in blocking mode, this message is rejected, no further messages are written to the corresponding Rx FIFO until at least one message has been read out and the Rx FIFO Get Index has been incremented. Since the message is lost it is possible it can cause an error. 

Regards,

Sean

Sean, 

Thank you for the detailed response. I am going to go ahead and consider this closed and post my question to the MCU group. We are not getting past error passive so there must be something stopping the erroneous behavior before we get into bus-off. I am going to dig into the issue with the MCU group. Thank you for your help. 

Regards

ds