• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 34 subscribers
  • Views 76 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.

TCAN4550: Test Register function in Test Mode

AP
Intellectual 530 points

Part Number: TCAN4550
Other Parts Discussed in Thread: ISO1044

Hello,

we are using the TCAN4550 in Test Mode with TEST_MODE_CONFIG = 1 (so GPO2 acts as TXD to and GPIO1 acts as RXD from an external transceiver).

In this mode, should the Test Register at 1010h be functional to set the GPO2 = TXD device pin? E.g. Test Register has been set (and read back) to be 000000C0h, but we don't see any change (no dominant level) on the GPO2 pin. It seems m_can_tx is not the same as TXD_INT_CAN?

Thanks

  • 0
    TI__Mastermind 37451 points

    Hello AP,

    Yes, the MCAN Test Register 0x1010 should be functional.  Do you have an external transceiver connected to the GPO2 and GPIO1 pins?  Could you provide some more information about your test configuration?

    Please read back the final values for the following registers:

    0x0800

    0x1018

    0x0820

    0x1050 or 0x0824

    How are you trying to create a Dominant value on the TXD (GPO2) pin?  Are you trying to send a CAN message, or force the TXD pin to a Dominant level through the Test register?

    Regards,

    Jonathan

  • 0
    Intellectual 530 points

    Hello Jonathan,

    Yes, we have an ISO1044 as external transcevier. TCAN pin 9 (GPO2) connects to ISO1044 pin 2 (TXD input).

    We were trying to send a CAN message. Since we did not see any dominant level on the I/O line, we are now trying to use the Test Register to force a dominant TXD level on GPO2 (Pin 9). No success so far. Register values are:

    f7c00800: C82004A3
    f7c00820: 000001A0
    f7c00824: 00000000
    f7c01010: 000000C0
    f7c01018: 00000083
    f7c01050: 00000000

    Thanks

  • 0 in reply to AP
    Intellectual 530 points

    BTW: I just noticed in the TCAN4550 data sheet, register description 830h: Figure 47 shows CANDOM access type R (only) while Table 21 shows CANDOM access type R/W. Also strange?: Even when I disable the CANDOM interrupt in 830h, I still get it in 820h.

    Sequence:

    0820h read > 000001A0h (CANDOM interrupt status set)

    0830h read > 809628FFh (Bit 8 is clear, CANDOM interrupt disabled)

    0820h write: FFFFFFFFh (clear all R/WC interrupts)

    0820h read > still 000001A0h (unexpected?)

  • 0 in reply to AP
    TI__Mastermind 37451 points

    Hi AP,

    Yes, the device is saying it detects the CAN bus is stuck dominant, which is why it is not going to try to send a CAN message, or do something else.  Just disabling the interrupt bit in register 0x0830 will not cause the interrupt bit to be disabled, but it will disable this particular bit from generating a hardware interrupt on the nINT pin.  

    I also see that you have the SWE_DIS = 1 in register 0x0800[1].  Please keep the SWE_DIS bit at the default value of "0" when using the device in Test Mode. 

    Can you retry your testing with SWE_DIS = 0?  I believe clearing this bit when using the device in Test Mode should allow you to transmit a CAN message and prevent the need to try to use the MCAN TEST register to force a dominant.

    Regards,

    Jonathan

  • 0 in reply to Jonathan Nerger
    Intellectual 530 points

    Hello Jonathan,

    SWE_DIS = 0 seems to do the trick, so basically CAN message transmission seems to work now.

    We can also stimulate the GPO2 = TXD output pin via the MCAN Test Register. It seems that a dominant level (TXD low level) cannot really be forced, instead we are seeing a low pulse (then back to recessive/high).

    Another question came up for future projects using the TCAN integrated transceiver (and not an external transceiver): It seems that CANH and CANL are driven low during active RST# and while in Standby Mode. Is this correct? For our understanding: Would this make the CAN bus unuseable for other nodes at these times?

    Thanks

  • +1 in reply to AP
    TI__Mastermind 37451 points

    Hello AP,

    I'm glad I could help resolve the original issue.

    The Dominant Time Out prevents you from forcing a Dominant state indefinitely and it will force the state back to Recessive after the timeout has expired.  So you should expect to just see a pulse when you manually set the test state to Dominant.

    You are correct that the CANH and CANL pins are biased to GND instead of VCC/2 when the device is not in Normal Mode.  This is not a problem for other nodes and will not interfere with bus communication.  Each pin has an input resistance of approximately 40kΩ or a differential resistance of 80kΩ.  When this is placed in parallel with the typical CAN bus termination resistance of 60Ω, the impact to the common mode voltage and bus impedance is negligible. 

    Regards,

    Jonathan