• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 787 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.

TCAN1146-Q1: TCAN1146-Q1

Frank Tsai
Prodigy 60 points
Part Number: TCAN1146-Q1
Other Parts Discussed in Thread: TCAN1044A-Q1, TCAN1145-Q1, TCAN1043A-Q1

Hi There,

According to TCAN1146 datasheet addressed:

"The devices are configured using serial peripheral interface (SPI) for access to full functionality.

Because the SPI port quantity of our MCU is limited, I'm afraid there is no  

May I know if we only connect the UART port (TXD/RXD), and leave the SPI interface as no connection, what's the affection here? can I assume the CAN function still work properly?

Frank

  • 0
    TI__Guru 74262 points

    Frank,

    Unfortunately the device mode transitions rely on SPI, so if there is not SPI communication, you'll be stuck in standby mode with no CAN communication function. If you just need a CAN transceiver with no SPI, the TCAN1044A-Q1 or the TCAN1043A-Q1 would work. The TCAN1145-Q1 and TCAN1146-Q1 are typically chosen because of the partial networking capability, is this something you need?

    Regards,

    Eric Hackett 

  • 0
    Prodigy 60 points

    Hi Eric,

    Yes, your reply is crystal clear to me. Thanks for your prompt reply.

    Our demand is simply a CAN transceiver with the "selective wake" function, no need on SPI,  I checked the TCAN1043A-Q1 can't meet our requirement.

    Is there any recommendation you can bring up to us?

    Frank

  • +1 in reply to Frank Tsai
    TI__Guru 53555 points

    Hi Frank,

    Unfortunately, all of our selective-wake-capable devices are currently configured using a SPI interface. 

    Note that the SPI for these devices is only required during mode change and initialization. So SPI bandwidth will not be required during normal operation. Would it be possible for the TCAN1146 to share the SPI lines with another peripheral for the purpose of configuration? Once the system moves into a normal operating mode, the SPI bandwidth can be entirely dedicated to the other peripheral until a mode change or reconfiguration of the CAN transceiver is required. The only additional hardware requirement for this would be an extra GPIO for the chip select (nCS) of the TCAN1146. Do you think this is a possible solution given the customer's current implementation of SPI?

    Regards,
    Eric Schott

  • 0 in reply to Eric Schott1
    Prodigy 60 points

    Hi Eric,

    Thanks for your solution for us. Unfortunately, the MCU that we used has total 8 multi-function ports and all of them are occupied and configured as UART or I2C functions, no any existed SPI interface can be shared there...

     Anyway, I would try to consult the MCU supplier to see if there is any solution from them.

    Thank you

    Frank

  • 0 in reply to Frank Tsai
    TI__Guru 74262 points

    Frank,

    Thanks for further information, and please let us know if there are any other questions you have.

    Regards,

    Eric Hackett 

  • 0
    Prodigy 60 points

    Hi Eric,

    For TCAN1146, would you please check if the SPI and UART always work in the different time slots? If the answer is positive, maybe we can connect them to the same physical multi-function port on our MCU.

    This idea comes from our MCU supplier, they claimed that if the SPI interface only works on mode change and initialization, then the target multi-function port can be config as  SPI first, when initialization or mode change was completed, they can configure it as a UART port for CAN bus then.

    The question here is how do we know what time the MCU shall switch the configuration from one to the other? How long does the initialization time TCAN1146 need? When does TCAN1146 need to change mode? Is there any way the TCAN1146 informs the MCU first before it starts changing mode?

    Please feel free to let me know if you think it works.

    Thanks.

    Frank

  • 0 in reply to Frank Tsai
    TI__Guru 74262 points

    Frank,

    Yes, this could indeed work. Once the device is configured for partial networking and transitioned into sleep mode (or normal mode), then SPI is no longer needed. At any point that a mode transition would be needed, CAN communication wouldn't be occurring from that node, so UART communication could be stopped, and SPI could then be used to transition the device mode or be reconfigured.

    The INH pin will be high in standby and normal mode, and then go low in sleep mode. This is one way that the device mode will be externally indicated, though since this is a high-voltage pin it's not able to be directly read by the MCU. The mode change register can also be used to read back the state of the device through SPI, so what could be done when configuring for partial network and then going to sleep is to put a *SPI read at the end of the configuration that verifies the state the device is in. For going from sleep to standby, the RXD pin will go low indicating a wake event, and the MCU would then know the device is no longer in sleep mode and can be transitioned to normal mode. Then, UART communication could be used for CAN communication switching away from SPI.

    Does this make sense?

    Regards,

    Eric Hackett

  • 0
    Prodigy 60 points

    Hi Eric,

    I think it may work. However, I still have some concerns if SW can handle it well because, on our project, there will be 3 SPI devices on the same SPI BUS. I worry it will be too completed to handle well by our MCU if we want it to switch the IO definition between SPI/UART/I2C mode (EEPROM of MCU ID ROM).

    Finally, we decided to adopt your first suggestion, that's MCU use one SPI BUS to control one ID ROM (will change it to SPI NOR), and two CAN transceivers (TCAN1146), I believe this solution has the most feasibility and cost-benefit for us.

    I really appreciated your professional reply and useful suggestion. It does help a lot.

    We can close this case.

    Frank