Electronic – How to CAN transceivers ouput CANH=3.5V and CANL=1.5V

automotivecandiodesmosfettransceiver

When sending a dominant bit (0bit) on the CAN bus, I understand that CAN transceivers output CANH=3.5V and CANL=1.5V.

But when looking at the schematics of a CAN transceiver, I do not understand how the CANH=3.5V is achieved (figure as follows borrowed fro TI blog post).

Does the Schottky diode (in the picture) along with the transistor make the 1.5V drop? Based on the fact that Schottky diodes drop very low voltage (~0.5V), I can't imagine the MOSFET dropping 1.0V. Especially when the drain-to-source resistance is a few mOhms for CAN transceivers.

Anyone can explain how the 1.5V drop from Vcc=5V to CANH=3.5V is achieved?

Best Answer

A properly sized MOSFET can provide extremely low voltage drops, at the expense of increased die size. For instance, power MOSFETs routinely provide on resistances in the milliohm range. Of course, this is at currents of 10s of amps. For CANBus, the currents involved are far less, so the FETs don't need to be as large. But let's say the FET is sized for 0.1 volt drop at the desired current. Then the total drop within the driver will be about 1.2 volts (2 x 0.1 plus 2 x 0.5), leaving 3.8 with a 5 volt supply. This is comfortably greater than the minimum requirement of 3.5.

And yes, there is process variation between chips, so the actual voltage across the termination resistor(s) will vary a bit. But, of course, that's the beauty of digital - as long as the voltages are within tolerance nobody cares about the details.

EDIT - And the 1.5 limit represents the sum total of all of the leakage currents through the MOSFETs which have been turned off. Since there can theoretically be on the order of 127 such units, even small leakage currents could add up.

Related Solutions

Electronic – Issue with the AMIS42700 CAN bus extender

The issue with the AMIS42700 chip is that when trying to broadcast a message to all nodes, it seems to keep sending the same message repeatedly

This implies that the problem could as well be on the CAN controller level. There must be at least one CAN controller present who will acknowledge the reception of the message, or otherwise the controller will keep trying 128 times. Some troubleshooting to check:

Check for error or bus off flags from the transmitting CAN controller. Ensure that no CAN controllers are set to filter out certain identifiers. Ensure that they aren't in "listen-only" mode where they won't ack received frames. Ensure that no controller is in loopback mode (only talking with itself).
Do you get error frames on the bus or actual data? If you look for error frames with a plain oscilloscope, they look like small, single pulses. While data frames look like a train of binary ones and zeroes.

(For an error frame, it should start with 6 bits, which are either dominant or recessive depending on what error state the sending node is in: active error state=dominant bits, passive error state=recessive bits. A node is in active error state until after 128 attempts, when it reverts to passive and can no longer mess up bus arbitration. No matter if active or passive, this part of the frame violates the "bit stuffing" rule on purpose. CAN usually only tolerates up to 5 bits of equal level before using bit stuffing. So the only time when you should encounter 6 bits with same level in a row is during the error frame.)

What does the enable signals EN1 and EN2 look like on the master? Are they stable?
Same problem when you disconnect the second "slave" AMIS from the bus?
I will always suspect the most classic serial bus problem: what is tx and what is rx? (As a rule of thumb/Murphy, you always get these wrong no matter what you do :) ) It would seem that the AMIS circuit will act as a data communication "modem" in this case, or if you will just as any other plain CAN tranceiver. In that case you'll have to ensure that CAN controller Tx goes to AMIS Tx. Your schematic looks correct, but I would always double-check this.
I doubt the terminator resistors have much to do with the problem, since termination-related problems either have no notable effect on the communication (the bus may work fine without proper termination, especially on lower baudrates) or they cause the whole bus to go down, ie they work or they don't. In case they don't, no slave would be able to send anything either.

However, in the datasheet application example of AMIS-42700 (p4), they seem to prefer 60 Ohm, which implies that each of the individual buses should have the normal 120 Ohm termination in each end. As in: add two more 120 terminators on each bus and treat them as two buses not one.
Probably needless to say, but signal grounds need to be the same for both buses. So if they are located on physically different locations, it is not enough to just connect the Text and Rint signals, you must also connect signal grounds.

Strangely, when disconnecting one of the CAN lines (CANH or CANL) at a time, the communication could be established between nodes. In that case though I did not check CANH and CANL at the oscilloscope.

CAN is very rugged, so even when you do such evil things to it, it may still be able to "limp home" if you are lucky.

Electronic – STM32 HAL_CAN_Transmit always returns TIMEOUT (HAL_CAN_STATE_TIMEOUT)

I got the new version and what a difference there are quite a couple of changes to keep in mind so here are some snippets:


// To send a message
// Old version:
HAL_CAN_Transmit(&hcan1, 10);

//new version:
HAL_CAN_AddTxMessage(&hcan, &TxMessage, TxData, &TxMailbox); 

//To receive a message by polling
        Receive_CAN_Message_Polling(RxMessage, RxData);     

// here is the Polling Function 

void Receive_CAN_Message_Polling(CAN_RxHeaderTypeDef RxMessage_, uint8_t* RxData_){
    uint8_t messages = HAL_CAN_GetRxFifoFillLevel(&hcan, CAN_RX_FIFO0);
        if(messages > 0){
            if(HAL_CAN_GetRxMessage(&hcan, CAN_RX_FIFO0, &RxMessage_, RxData_) == HAL_OK){
            Indicate();             
        }
    }
}

much different to the old Library but it works very well I have not yet looked at the Interrupts and receiving with them but I am sure that they also work fine in the new version of the HAL_CAN Driver

Best Answer

Related Solutions

Electronic – Issue with the AMIS42700 CAN bus extender

Electronic – STM32 HAL_CAN_Transmit always returns TIMEOUT (HAL_CAN_STATE_TIMEOUT)

Related Topic