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-Q1: timeout functions

Part Number: TCAN4550-Q1
Other Parts Discussed in Thread: TCAN4550

Hi,

In the standard MCAL driver code package of TCAN4550-Q1, the document describes that some CAN operation timeout functions are not supported, which means that the CAN will be blocked in some cases. I would like to ask if there is a workaround solution for the standard AUTOSAR requirements not supported in this part. Thank you!

  • Hi Mingkang,

    I support the TCAN4550-Q1 in this forum at a Physical Layer and Register Configuration level and I can help you with the proper device configuration questions, but I am not an AUTOSAR expert.  Many of these AUTOSAR driver requirements are at a higher abstraction level than the TCAN4550-Q1 which may not have hardware features internal to the device that directly supports these requirements.  However, there may also be features that the TCAN4550-Q1 supports that were not implemented or supported in the standard driver code.

    Your question is very broad and generic so perhaps you can be more specific about what features you need to support, and I can help determine whether the TCAN4550-Q1 can support that through it's register configuration.

    • Hardware wakeup is not supported.

    The TCAN4550-Q1 does support hardware wake-up through the WAKE pin.  This is a hardware feature of the TCAN4550-Q1 itself and operational by default.

    • TTCAN is not supported.

    The TCAN4550-Q1 uses the Bosch M_CAN Revision 3.2.1.1 IP for the CAN FD Controller instead of the M_TTCAN IP.

    • Automatic Bus-Off Recovery is not supported.

    The TCAN4550-Q1 meets the requirements of ISO 11898-1:2015 and ISO 11898-2:2016. If the error counters reach the point where the device enters a Bus-Off condition, the device will have to be re-initialized by the MCU and the TCAN4550-Q1 has no internal mechanism for re-enabling CAN communication by itself.

    • SWS_Can_00281

    I'm not sure why you have highlighted this Requirement ID in particular.  This appears to be a requirement from the system to ensure that the TCAN4550-Q1 has not suffered from some malfunction and is communicating within the required and expected timelines.  The TCAN4550 has many interrupt and fault status bits that can be monitored.  It also can provide indication of successful CAN message transmission with timestamps and the TX Event FIFO.  However, if the TCAN4550-Q1 has suffered some sort of hardware malfunction, or the response time is too long, then this would need to be monitored and determined by the MCU and not the TCAN4550-Q1.

    Regards,

    Jonathan