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.

TCAN1145-Q1: Device can't enter normal mode

Part Number: TCAN1145-Q1

Dear team,

After powering up, my customer write 0x10=0x07 to our device to enter normal mode, but our device has no response. I am not sure whether we need to make more operation to enter normal mode. We read 0x00 register, SDO output two bytes, one is 0x50=0xA0, and another is 0x00=0x54. The 0x00 register value is correct, but the 0x50 seems incorrect. We need to clear these interrupt, then we can enter normal mode, right?

In addition, we also test the SCK rise time, in the datasheet, the max value is 40ns, but the actual SCK rise time is ~45ns. Why does our device has this limit? If SCK rise time is larger than 40ns, is there any bad impact?

Thanks & Regards,

Sherry

  • Sherry,

    An applications engineer has been notified of this thread and will respond accordingly. Thank you for your patience.

    Regards,

    Eric Hackett

  • Hi Sherry,

    The INT_GLOBAL register (50h) is expected to have this value during startup. The set bits indicate [7] an interrupt is active (global interrupt) and [5] an interrupt in INT_2 register is set. The INT_2 register includes the [6] power-on interrupt which is automatically set after power is initially supplied. These interrupts should be cleared (write 1 to clear) before entering normal mode. Writing to the mode control register (10h) as you described is correct. 

    The SCK signal is an input to TCAN1145 and is driven by the SPI leader. The specification in the datasheet is a requirement of the clock input signal, not a characteristic of any drive capability (device cannot drive SCK). To reduce the transition time of this signal, you may be able to limit the capacitance of the trace or reduce the series resistance value of on the signal path. Because it looks like you are able to read from the device successfully, this may not be necessary. 

    Regards,
    Eric Schott