SN65HVD232: CAN Transceiver Pin Out Question

Archie,

Pin 8 on the SN65HVD232 is a true no connect meaning it has no connection to the internal die, so connecting this to GND should have no effect. Even if it were the case that there was an effect based on the other versions in this family (230, 231), it would place the device in normal mode and communication would work properly. 

Since this is an issue of the frame being transmitted, and the transceiver only has the capability to translate the message from the controller, this seems like it would stem from the controller. Are there any errors being reported in the controller as well, or just incorrect messages being sent? 

Regards,

Eric Hackett

Hello Eric,

Thank you. Client responded:

I thought that was likely the case for the transceiver, but we are at a point where have to examine every possibility and seemed like this would be easy one to cross out. Plus, have run into issues where NC just meant don’t connect anything and wanted to make sure we were not causing another issue that we might not be aware of yet.

In answer to your question, we are not seeing errors. Just the incorrect messages.

The microcontroller in question is the Microchip SAM E70 (in case you may have heard anything about any issues with it via forums …)

Regards,
Archie A.

Archie,

Understood, and thank you for the follow up. I haven't heard anything specifically about that microcontroller, but I was asking about errors because some CAN controllers will have the configuration where it will resend messages if it doesn't detect an ACK from other nodes on the bus. I don't think that is happening here, but it may be something to look into.

Please keep us updated on this issue in case there is anything else with which we can help.

Regards,

Eric Hackett 

Hi Eric,

Good day. I followed up with the customer and responded:

My apologies. The issue is not resolved, but it cannot be related to the transceiver.

We are still working with Microchip (but there was a temporary EAR delay).

There appear to be one of the following occurring:

• Collisions on the CANBus that arbitration is somehow not handling
• Internal hardware collisions during the transmit/receive area 

Everytime an echo occurs, it happens immediately after the legitimate receive message.

Since the receive message occupies the echo identifier and the legitimate transmit message occupies some of the data, almost appears as if bus collision is occurring but instead of a frame error, it stops at 2 data bytes. 

We are investigating a potential workaround of the issue.

Basically before moving items to the transmit H/W we ensure that the CANBus is at idle. Affects timing but haven’t seen the echo.

As we both figured, there is no way this can be caused by a transceiver chip. The case file may be closed.

Thank you again for your time.

Regards,
Archie A.