Tool/software:
Hi Expert,
We want to know if TI's SBC (such as TCAN284x-Q1) can support CAN 2.0 and CAN FD wake-up and could you share some documents about this? Thanks.
Best Regards,
Ryker
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.
Tool/software:
Hi Expert,
We want to know if TI's SBC (such as TCAN284x-Q1) can support CAN 2.0 and CAN FD wake-up and could you share some documents about this? Thanks.
Best Regards,
Ryker
Hi Ryker,
CAN 2.0 is a specific reference to an update to the CAN standard that allowed for extended 29-bit IDs to be used. This does not impact Normal communication for any transceiver supporting only the physical layer. The selective wake functionality of the TCAN2845 also supports extended ID filtering, so CAN 2.0 can be supported by this device.
"CAN FD wake-up" does not refer to a known feature. Standard wake up pattern (WUP) wake for any of our transceiver's will be compatible with CAN FD frames, as the arbitration phase - which is still transmitted at classic CAN rates - will satisfy the timing requirements for a WUP. If this is the requirement here then TCAN2845 or any of our other CAN FD transceiver can support this.
If this is referring to the ability to use selective wake to wake on a specific CAN FD frame, this feature is not defined by the CAN standard and does not exist in the market. Partial networking is designed to work with classic CAN frames. Because all CAN FD CAN controllers and transceivers are backwards compatible, this is possible to implement in any system. The timing differences between a system waking to a classic CAN or CAN FD frame are negligible and would not provide any real benefit. A PN phy supporting FD wake would also be significantly more complex in order to decode the higher data rate signal. For these reasons I do not believe that such a feature will be defined for use in any ISO compliant CAN systems.
Let me know if you have any more questions.
Regards,
Eric Schott
Hi Eric,
Thanks for your explanation. My customer need to realize below function:
When there are CAN 2.0 and CAN FD messages on the CAN bus (sometimes only exists CAN FD message), the system only wakes up the ECU after receiving a specific CAN FD message ID or data. Could you help to confirm if TI's SBC can support that? Thanks.
Best Regards,
Ryker
Hi Ryker,
The partial networking feature allows the transceiver (or SBC in this case) to wake for only a specific CAN ID with optional data filter as well. However this feature is only designed to work for classic CAN 2.0 frames. The TCAN284x devices can be configured to ignore CAN FD frames so these can be present on the bus while the SBC is in Sleep mode without interfering with the wake method. The wake up frame (WUF) itself though will need to be formatted without the FD bit and bit-rate-switch enabled. This will be possible for any CAN FD controller.
Based on your description, the TCAN284x will be able to support what the customer is ultimately looking for. I think some of the specifics may need some clarification based on how this functionality is implemented in the current market, but the overall functionality will be more than possible with this device.
Regards,
Eric Schott
Hi Eric,
But customer need the SBC can be waked up by CAN FD frames and they don't want to ignore the CAN FD frames. Because sometimes only exists CAN FD frames on the CAN bus, they need to use CAN FD frames to wake up SBC.
BR,
Ryker
Hi Ryker,
Selective Wake on CAN FD frames is not a feature that exists in the market. The CAN standard only specifies wake up behavior for wake on classic CAN frames. The system will have to be modified to send classic CAN frames when it needs to address the customer node while in Sleep mode. This is easily done with a small software modification and will be necessary to implement selective wake with any CAN device on the market.
Please stress to the customer that lack of support for wake on CAN FD is not a limitation of our device, but an intentional omission by the ISO CAN standard.
Regards,
Eric Schott