This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TCAN330: Design Question

Part Number: TCAN330

Dear Team,

My customer is surveying CAN controller and CAN transceiver solutions for their CAN device.

Here are some requirements of CAN solution:

1. 1Mbps datarate (No need CAN FD)

2. Need to support SAE J1939 spec.

Now they prefer to choose TCAN33x series solution, but they have some questions below. Please help to advise.

1. TCAN33x is compliant with 11898-2, so it should be able meet SAE J1939. But do they need to choose a CAN controller which is compliant with SAE J1939 as well? 

2. Once the CAN device is ready. How could they test its function and signal quality? Is there any test flow for the CAN product that I can share to the customer?

3. Is there any driver (for Linux) or sample code support?

4. Is there any risk that if they choose the CAN controller from another vendor but use TI CAN transceiver? Any compatibility problem?

Thank you.

Jim

  • Hi Jim,

    While TCAN330 can interoperate with ISO 11898-2-compliant transceiver implementations, it is not fully compliant to ISO 11898-2 itself due to the lower supply voltage. While it was designed to be able to meet the ISO requirements for differential output amplitude, the single-ended (ground-referenced) voltages on each CANH/CANL line may be lower than what ISO 11898-2 requires. This should not cause communication issues (since CAN signaling is differential in nature and intended to work across a relatively wide common-mode voltage range), it does create a standards compliance issue.

    In general, SAE J1939 requirements are not identical to ISO 11898-2. (The ISO standard is more general in scope, while the J1939 series of standards define requirements for specific use-cases.) If you can tell me the J1939 standard that is being implemented I can check on whether or not TCAN330 could comply to it. (Or, if you know the application data rate and cable type I may be able to find the relevant J1939 standard.)

    There are several ways of verifying CAN bus functionality. One would be to monitor whether the frames from one node are being properly received by all the other nodes in a network. (This is something that would be implemented at the application level, although it is useful to note that transmit and receive error counting is something implemented in the CAN protocol and should be supported by most controllers.) Another method would be to observe the CANH/CANL signals on an oscilloscope to verify proper signal amplitudes, bit timings, etc. Another method would be to use a CAN bus analysis tool - some oscilloscopes will offer these as software packages, and there are some dedicated solutions as well such as Vector's CANalyzer.

    We do not provide any software support or references for these transceiver devices, but since they implement the interface per the standard definition any existing CAN driver should work with them.

    I would not expect compatibility issues between a controller and a transceiver. However, sometimes some minor changes to the controller configuration may be needed in order to support a new transceiver. For example, the bit timing/sampling point configuration may need to change slightly if a transceiver introduces a different amount of delay than the controller was originally configured for. (This would be an issue more likely to occur at high data rates such as those used by CAN FD.)

    Max