• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 34 subscribers
  • Views 127 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

TCAN4550: CAN controller + CAN Transceiver solution with isolation

TCAN4550: EN_INT in Test Mode

AP
Intellectual 510 points

Part Number: TCAN4550

Hello,

a question regarding the TCAN4550 used in test mode.

The data sheet states: "In test mode, this pin is used as an EN pin input for testing the CAN transceiver and is shown as EN_INT throughout the document. When this pin is high, the device is in normal mode and when low it is in standby mode" (it says "the device", not "the internal transceiver").

I would like to use the test mode configuration according to Figure 29 SPI and M_CAN Core Test Mode (using the MCAN core with an external transceiver), which does not show the EN_INT pin. So the mode would be: TEST_MODE_CONFIG = 1, CAN Controller test with TXD/RXD_INT_CAN mapped to
external pins.

In Figure 28 (TEST_MODE_CONFIG = 0) EN_INT is shown as internal transceiver enable control where a low would disable the integrated transceiver I guess.

How should the EN_INT pin be configured (or pulled) for having (a) the device in normal operating mode and (b) the internal transceiver disabled, with TEST_MODE_CONFIG = 1? Is there any EN_INT functionality left at all with TEST_MODE_CONFIG = 1?

Thanks

  • 0
    TI__Mastermind 36451 points

    Hello AP,

    AP said:
    In Figure 28 (TEST_MODE_CONFIG = 0) EN_INT is shown as internal transceiver enable control where a low would disable the integrated transceiver I guess.

    Correct.  The internal transceiver's enable input is mapped to the nINT pin so that the transceiver can be operated in a similar fashion to a standalone transceiver.  Because this enable input is "internal" to the device when the TCAN4550 is not using a "test mode" this EN signal is referred to as EN_INT meaning that it is the "Internal Enable" signal to the transceiver.  The RXD and TXD signals also use the same "INT" designation because these are normally internal signals mapped between the MCAN core and the internal transceiver.

    AP said:
    How should the EN_INT pin be configured (or pulled) for having (a) the device in normal operating mode and (b) the internal transceiver disabled, with TEST_MODE_CONFIG = 1? Is there any EN_INT functionality left at all with TEST_MODE_CONFIG = 1?

    The EN_INT signal is only mapped to the nINT pin when TEST_MODE_CONFIG = 0 because it is tied to the internal transceiver.  When TEST_MODDE_CONFIG = 1, the internal transceiver is not used and disabled, and the nINT pin will operate as the global interrupt pin in the same way as if the TCAN4550 was not operating in a test mode. 

    The MCAN core will be placed into normal or standby modes through the MODE_SEL field in register 0x0800. 

    During a normal operation that uses both the MCAN and internal transceiver, the transceiver is enabled and disabled along with the MCAN controller based on the MODE_SEL field value.  However, when the device is used in the Transceiver Test Mode, the state of the MCAN controller is irrelevant to the transceiver and therefore the transceiver's enable state must be controlled through an external input pin connected to the device that does contain the CAN controller connected to the TXD and RXD signals.

    Regards,

    Jonathan

  • +1
    Intellectual 510 points

    Hi Jonathan,

    Jonathan Nerger said:
    When TEST_MODDE_CONFIG = 1, the internal transceiver is not used and disabled, and the nINT pin will operate as the global interrupt pin in the same way as if the TCAN4550 was not operating in a test mode. 

    Ah Ok. From the data sheet we thought that even with TEST_MODE_CONFIG = 1, the nINT pin function would no longer be available. That's good news and would spare us from performing permanent SPI transfers to get the status byte.

    OK, thanks.