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: Need more documentation about timestamp and data rate configuring

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

I am using the TCAN4550-Q1 and some features do not appear to be explained in the documentation.  There are some also notes in comments in the sample code that I don't find in the documentation.  Here are my questions.  If you can answer them and also tell me where I might find documentation that answers them, that would be very helpful.

1. I'm trying to understand the Timestamp counter.  The sample code (in sllc469b.zip) sets TSCC to use the external time stamp value.  It says "This is required to use time stamps with CAN FD".  Where is this mode documented?  What happens if I configure FD for internal timestamps? What is the timestamp count frequency in this case?  Does this mean I need to supply an external clock somehere, or is some other hardware change needed?  Some places in the documentation talk about CAN bit times.  For FD, is this the nominal bit time or the data bit time, or does the time base actually vary when the bit time switches?  How can I know what units of time the FD packet timestamps represent?

2. The sample code tries to set the CCR register several times.  Is setting this register not reliable?  Why not?

3. I need to be able to set many different data rates.  I can calculate the period, but what is the best way to calculate the NominalTqAfterSamplePoint and DataTqAfterSamplePoint.  The code examples for a nominal period of 40 sets Tq after sample point to 8, but for the data period of 20, it sets Tq after sample point to 5.  It looks like maybe setting it to Period/4 or Period/5 would work, but what is the best setting?

4. I can get all the nominal and data rates I need setting the prescaler to 1.  Is there any good reason to set it to a larger value?

5. The GFC register documents RRFE and RRFS bit, but the sample code has these lines:

    gfc.RRFE = 1;                                               // Reject remote frames (TCAN4x5x doesn't support this)
    gfc.RRFS = 1;                                               // Reject remote frames (TCAN4x5x doesn't support this)
Is it true that this is not supported even though it is documented in the data sheet?  Why does the sample code set these bits?



  • A couple more questions:

    Some places in the data sheet say this part supports up to 8 Mb/s, but other places say 5 Mb/s.  You can see both of these numbers in the first paragraph of section 8.1.  The only way I can make sense of this is maybe the controller only runs up to 5 Mb/s but transceivers can run up to 8 Mb/s, which is only useful when bypassing the controller, as in test mode.  Is that correct?

    When I do the detailed calculations, I cannot find any settings for >= 4 Mb/s that meet the PROP_SEG timing requirements in the Bosch spec.  For example, for 4 Mb/s, and a prescaler of 1, the period is 10 Tq, and the time segment after the sample point must be at least 2 Tq.  If PHASE_SEG1 = PHASE_SEG2, we have PROP_SEG = 5 Tq, or 125ns.  The worst case Tx delay + Rx delay from the data sheet add up to 200ns, which is already longer than PROP_SEG, not counting any propagation time at 5ns/M.  It seems it is not possible to meet the spec with these data rates.  Is that correct?

    Second question: The Bosch spec says that for the FD data rates (as opposed to the nominal rates), PROP_SEG, PHASE_SEG1, PHASE_SEG2 must all be <= 8 Tq.  The sample code configures this with PHASE_SEG2 = 5, which must be the same as PHASE_SEG1 in this case.  Since SYNC_SEG = 1, this makes PROP_SEG = 9, which does not meet the spec.  PHASE_SEG2 = 6 should meet the spec, making SYNC_SEG = 7.  This is 175ns, less than the transciever propagation times.  My question is, have I read the spec and data sheet correctly?  Is there really a limit of 8 Tq for each of the phases listed in the Bosch spec?

    Any guidance on configuring this part for 2, 4, 5, or 8 Mb/s would be helpful.

    Thanks much to anyone who can help!

  • Hi Edwin,

    First off thank you for your interest in the TCAN4550-Q1 and I will do my best to answer all of your questions.  However, in your most recent post, you mentioned "requirements in the Bosch spec."  Can you let me know specifically what specification or document you are referring to?  Can you give me the title and or a link so that I can make sure I understand the context of your question?  Thanks!

    I will try to address all of your questions starting with your first post:

    I am using the TCAN4550-Q1 and some features do not appear to be explained in the documentation.  There are some also notes in comments in the sample code that I don't find in the documentation.  Here are my questions.  If you can answer them and also tell me where I might find documentation that answers them, that would be very helpful.

    TI licensed and used the CAN FD Controller IP developed by Bosch called M_CAN when developing the TCAN4550-Q1.  This M_CAN controller is well documented by Bosch, complete with a dedicated Users Guide that is a great resource and supplement to the TCAN4550-Q1's datasheet.  It is not practical to duplicate all of Bosh's documentation inside the TCAN4550-Q1's datasheet, especially since it is already documented by Bosch. While the register names and bit descriptions specific to M_CAN have been included in the datasheet, the datasheet focuses on the overall device features and explains in more detail how to configure the modes of the device but leaving the M_CAN specifics to the existing documents.  There are only minor adjustments made to some of the supported register bits that were not compatible or supported in the TCAN4550, but otherwise the M_CAN register base address and bit fields have remained unchanged.  The TCAN4550-Q1 does add an offset of 0x1000 to the M_CAN base address, but outside of that they are the same.  For example, the CCCR register base address shown in Bosch's M_CAN documentation is 0x18 and the TCAN4550-Q1 implementation is 0x1018.  Any registers less than the 0x1000 offset are TCAN4550 specific.  The Device ID and Interrupt/Diagnostic Flag Registers 0x0000 to 0x002F are dependent only on the SPI clock for read/write access.  And the registers with a 0x0800 offset (registers 0x0800 to 0x08FF) are TCAN4550-Q1 specific and require the Crystal OSC / CLKIN clock to be active and interact with the digital core.

    More information on the Bosch M_CAN CAN FD Controller can be found on their website at the following link.

    https://www.bosch-semiconductors.com/ip-modules/can-ip-modules/m-can/

    CAN in Automation (CiA) is the Independent organization responsible for overseeing and managing the ISO CAN Standard documentation.  Their website is full of useful documents, app notes, and recommendations.  If would recommend using the information on their website for more generic CAN related information.

    https://www.can-cia.org/

    I would also reference all of the documentation found on the TCAN4550-Q1’s Product Folder, specifically the Software Configuration Guide.

    https://www.ti.com/product/TCAN4550#tech-docs

    1. I'm trying to understand the Timestamp counter.  The sample code (in sllc469b.zip) sets TSCC to use the external time stamp value.  It says "This is required to use time stamps with CAN FD".  Where is this mode documented?  What happens if I configure FD for internal timestamps? What is the timestamp count frequency in this case?  Does this mean I need to supply an external clock somehere, or is some other hardware change needed?  Some places in the documentation talk about CAN bit times.  For FD, is this the nominal bit time or the data bit time, or does the time base actually vary when the bit time switches?  How can I know what units of time the FD packet timestamps represent?

    I will admit, the timestamp documentation could be better and the references to “internal” and “external” are a bit confusing. This comes from the vantage point of the M_CAN controller. I would suggest you read the more detailed description of the timestamp counter in the M_CAN user’s guide, but I’ll give a brief overview.

    There is an “Internal” timestamp counter inside the M_CAN controller core that counts in multiples of CAN bit times. This is controlled in register 0x1020 (note this is an M_CAN register because of the 0x1000 offset). The Timestamp Counter Prescaler TCP[3:0] can be configured to count in multiples of 1 to 16 bit times as set with this register. The current Counter value can be read from register 0x1024 and at any time can be cleared or re-started by writing to 0x1024 if the “internal” counter has been configured for use. I will also note that I believe the device will use the Nominal Bit Times to count and does not count the FD bits which would overrun the counters too frequently.

    The M_CAN controller allows for an alternative “External” timestamp counter to be used instead of the internal CAN bit time counter and it simply takes a 16 bit value from this external counter, but it doesn’t specify how this external counter should be implemented. The TCAN4550-Q1 uses a standard divider off of the Host Clock frequency (crystal/clkin) that allows for a divided down clock value to be used as the time stamp. If you select a TSCC.TSS[1:0] value of “10” (register 0x1020) then this “external” timestamp counter will be used. And by “external” it simply means that it is external to the M_CAN Controller Core. But since this is a TCAN4550 specific feature, its prescaler is setup in register 0x0804. Notice the address offset indicates this is not an M_CAN core register. By default this register has a value of 0x02, which will yield a clock divider of 16. Writing the pescaler value to this register will clear and re-start the Counter. When this counter is configured for use, the counter’s current value can be read in register 0x1024 which is the same register as the Internal counter since there is only one counter that can be used at a time.

    I will also note that you should add into the configuration routine a timestamp counter reset for which ever counter you chose to use so that once you start communicating on the CAN bus, you have a deterministic starting point for the counter values. Every time the counter wraps around, it will set an interrupt bit so that the MCU can keep track of how many times the counter has re-started. If this is important to you, I would suggest you have some form of secondary counter in the MCU to keep track of these wrap around interrupts which could be internally appended to the timestamp value captured from a message if the message is stored in some form of log.

    2. The sample code tries to set the CCR register several times.  Is setting this register not reliable?  Why not?

    This register is very reliable and is perhaps the most important register in the device. There is a simple and important reason that multiple writes are required for this register. Understanding how this register works and why is actually important to understanding how the TCAN4550-Q1 works.

    The majority of the configuration bits in the M_CAN Core are considered “Protected” bits and can’t be changed at any time. This is both a safety feature to ensure the settings are not changing inadvertently through either a bit error in the address field of another SPI write, or through some unauthorized access outside of the configuration and initialization mode that would result in errors in the CAN bus messages. Therefor there are two basic modes for the M_CAN core, an “initialization” mode and a “normal operation” mode. This is controlled through the INIT bit (bit 0) of the CCCR register (0x1018). The protected bits can only be accessed when the core is in the “initialization” mode i.e. the INIT bit = ‘1’ and therefore the first write to the CCCR register is to set the INIT bit to ‘1’. When this bit is set, the device will be unable to communicate in any way on the CAN bus, and I will note that this bit is also set automatically by the device when it enters the “Bus_Off” state after receiving too many TX errors. This is another common question, but when you need to clear a Bus_Off condition, the MCU will need to set the INIT bit back to ‘0’.

    However, just setting the INIT bit to ‘1’ does not necessarily allow the protected bits to be accessed and the CCE bit of the CCCR register (bit 1) must also be set to ‘1’. This is the Configuration Change Enable bit and setting this bit to 1 allows the MCU to have write access to the protected configuration registers. Once the INIT bit is set to ‘1’, this bit can be set to ‘1’ since it too is a protected bit. This is the reason for the second write to the CCCR register.

    Once both the INIT and CCE bits are set to ‘1’, can many of the other protected bits be accessed such as the ASM (bit 2) of the CCCR register which allows a change from the Normal to Restricted Operation mode to become active. This is just one example, but there could be a need for a third write to this register at which time all bits should be accessible. Many other registers require the M_CAN core to have both the INIT and CCE bits to be set to ‘1’ in order to change their settings such as the bit timing registers NBTP and DBTP. Once the device has had all the settings configured, the INIT and CCE bits should be set back to ‘0’ to place the device back into normal operation mode. As previously stated, this is not a reliability issue with this register, but a protection mechanism to ensure the stability and validity of the protected configuration bits.

    3. I need to be able to set many different data rates.  I can calculate the period, but what is the best way to calculate the NominalTqAfterSamplePoint and DataTqAfterSamplePoint.  The code examples for a nominal period of 40 sets Tq after sample point to 8, but for the data period of 20, it sets Tq after sample point to 5.  It looks like maybe setting it to Period/4 or Period/5 would work, but what is the best setting?

    I would recommend reading section 4 of the TCAN4550 Software User’s Guide (document number SLLU270). It is gives a pretty good overview of how to determine the proper values for these settings. You will need to do a little math. First you will need to know the crystal/clkin frequency you are using and determine the mTq or the “minimum time quatum” period. This is where one clock period is equal to 1 mTq. Then you will determine the desired bit rate (both nominal and data) and determine how many mTq are in each bit. Note, this must be an integer multiple and you couldn’t use a 24Mhz clock for a 5Mbps bit rate since 24/5 is not an integer.

    Once you have determined the number of mTq per bit, then you can decide if you want or need to use a prescaler on this to create a larger time quantum period resulting in fewer Tq per nominal or data bit period. Once again, there must be an integer number of Tq per bit and there must be at a minimum 4Tq per bit.

    When you have figured out how many Tq you are using in the Nominal and Data bits, you can calculate out the desired sample point. The optimal sample point will vary by system to system and this may need to be adjusted after performing some actual tests. However it is generally recommended to sample around the 80% location of the bit period. This is to allow for any noise or ringing that can occur in the bit following the bit transition to settle out before the RX bit is sampled. If you sample too early, you may sample the bit during a noisy ring and get an error. But you also do not want to be too close to the end of the bit period either because phase errors resulting from slightly mismatched clock frequencies between the Sending and Receiving nodes can cause the bit to be sampled on or after the transition.

    4. I can get all the nominal and data rates I need setting the prescaler to 1.  Is there any good reason to set it to a larger value?

    There are limits to how many Tq can be used for each bit, but generally it is recommended to use the highest number of Tq so that there is more resolution and accuracy to these settings allowing fine tuning in the adjustments. However, it is also recommended that the settings for ALL nodes on the bus match in both the number of Tq used, and the Sample Points. Any source for mismatch between the nodes can contribute to the phase error in the bits which can ultimately result in sampling errors. While it is not always known what other nodes on the bus have been configured to use, it should be noted that adjustments to these settings may be needed to get the overall system optimized. I would recommend trying to keep the prescaler set to 1 when possible, and only adjust it when necessary.

    5. The GFC register documents RRFE and RRFS bit, but the sample code has these lines:

        gfc.RRFE = 1;                                               // Reject remote frames (TCAN4x5x doesn't support this)
        gfc.RRFS = 1;                                               // Reject remote frames (TCAN4x5x doesn't support this)
    Is it true that this is not supported even though it is documented in the data sheet?  Why does the sample code set these bits?

    First off, Remote Frames are only used in Classical or Standard CAN communication and do not exist in the CAN FD protocol and CAN FD frames (FDF = ‘1’), the dominant RRS (Remote Request Substitution) bit replaces the bit RTR (Remote Transmission Request).

    The RRFE and RRFS bits are M_CAN bits, and the last paragraph in section 3.1.2 of the Bosch M_CAN User’s Guide states:

    “For Messages to be transmitted dedicated Tx Buffers and/or a Tx FIFO or a Tx Queue can be initialized or updated. Automated transmission on reception of remote frames is not implemented.

    The intent behind a Remote Transmission Request is for one node on the bus request data be sent from another node when it sends a CAN message with the RTR bit set to ‘1’. However, this requires the node receiving the request to have data ready to be sent automatically when receiving this request and to know several other critical pieces of information such as the ID and DLC values of the message. It has been shown that Remote Frames can lead to catastrophic errors on a bus and therefore the industry has generally recommended they NOT be used and instead use regular messages to achieve this purpose. Bosch did not implement the automated transmission of a data frame in response to a Remote Frame request, and therefore the TCAN4550-Q1 does not support this feature as well.

    However, the bits exist and remote frames could be sent to the device in a system even though it is not recommended or widely used. Therefore it is recommended to set the RRFE and RRFS bits to ‘1’ to reject these remote frames outright since they are not supported.


    A couple more questions:

    Some places in the data sheet say this part supports up to 8 Mb/s, but other places say 5 Mb/s.  You can see both of these numbers in the first paragraph of section 8.1.  The only way I can make sense of this is maybe the controller only runs up to 5 Mb/s but transceivers can run up to 8 Mb/s, which is only useful when bypassing the controller, as in test mode.  Is that correct?

    Ok, there is some confusion around what the device is “capable of” and what it is “certified” for. Currently the maximum CAN FD data rate that has any standards associated with it is 5Mbps. All parameters listed in the data sheet have been tested and certified as valid for a 5Mbps application based on the ISO 11898 standard and other relevant test criteria specified in the datasheet and has been independently tested and certified.

    However, the TCAN4550-Q1 is capable of running up to 8Mbps CAN FD data rates under the proper conditions even though no official standards exist to define performance requirements around this bit rate. So what does this mean? Basically if you are using a 40Mhz clock frequency you will have 5 Tq per 8Mbps data bit period. This doesn’t give you any margin for error, but if you have a small CAN bus that is very “clean” or free of noise and signal integrity reflections and artifacts that can cause bit errors such as in a 2 node point-to-point application then you can most likely crank up the bit rate to 8Mbps and get error free communication. You also have lot lower margin for clock frequency tolerance at these higher bit rates due to the fewer number of Tq per bit. Therefore while the industry only has ISO standard support for up to 5Mbps data rates, the device is capable of being configured for a faster rate.

    When I do the detailed calculations, I cannot find any settings for >= 4 Mb/s that meet the PROP_SEG timing requirements in the Bosch spec.  For example, for 4 Mb/s, and a prescaler of 1, the period is 10 Tq, and the time segment after the sample point must be at least 2 Tq.  If PHASE_SEG1 = PHASE_SEG2, we have PROP_SEG = 5 Tq, or 125ns.  The worst case Tx delay + Rx delay from the data sheet add up to 200ns, which is already longer than PROP_SEG, not counting any propagation time at 5ns/M.  It seems it is not possible to meet the spec with these data rates.  Is that correct?

    As I started off my response, I am unsure what Bosch specification you are referring too. I do not know where it is stated that “the time segment after the sample point must be at least 2 Tq.” There is no device limitation to prevent you from using 1Tq (which is the minimum possible) it could also be the only option you have at higher data rates. My previous statement on calculating the bit timing should also apply here. Setting the sample point at the appropriate location within the bit period is the most important factor. You need to be careful not to set the sample point too close to the end of the bit, but the percentage of the bit period each Tq uses will change with the bit rate and 1Tq at 5Mbps will be 12.5% of the bit period while only 5% of the bit period at 2Mbps. I am guessing the Bosch spec is a recommendation on the appropriate settings, but this is not any form of device limitation.

    To generally address the second part of your question regarding the PHASE_SEG1, PHASE_SEG2, PROP_SEG settings and Tx + Rx delay all fall under the topic of “Transmitter Delay Compensation.” Classical CAN only has a single sample point per bit period and therefore you can’t tolerate a large transmitter to receiver “loop delay” because the receiver must always be sampling the same bit that is being actively transmitted. Under this situation higher data rates are not possible and this has been addressed in CAN FD with what is called as Transmitter Delay Compensation.

    In CAN FD, a “Secondary Sample Point” is created for the data bit phase of the message which allows a “Transmitter Delay Compensation Offset” to be configured so that the loop delay is effectively calibrated out and the receiver is sampling the bit being transmitted even though the bit period is less than the transmitter to receiver loop delay. This is done by enabling the TDC it in the CCCR register and setting the appropriate offset value in the TDCR register. See section 3.1.4 of the Bosch M_CAN User’s Guide for more information.

    Second question: The Bosch spec says that for the FD data rates (as opposed to the nominal rates), PROP_SEG, PHASE_SEG1, PHASE_SEG2 must all be <= 8 Tq.  The sample code configures this with PHASE_SEG2 = 5, which must be the same as PHASE_SEG1 in this case.  Since SYNC_SEG = 1, this makes PROP_SEG = 9, which does not meet the spec.  PHASE_SEG2 = 6 should meet the spec, making SYNC_SEG = 7.  This is 175ns, less than the transciever propagation times.  My question is, have I read the spec and data sheet correctly?  Is there really a limit of 8 Tq for each of the phases listed in the Bosch spec?

    Once again I have no knowledge of this <=8Tq specification. I have always heard contradictory information to this and know that the device limitation is a maximum of 32 Tq can be used for a data bit. When combined with the recommendation to use the largest number of Tq possible per bit for the best accuracy and sampling resolution, I simply do not agree with the maximum limit of 8 Tq per data bit at this time. I would need to read the Bosch specification you are referring to myself in order to get a better context for the rationale behind this statement. But you can use up to 32 Tq per bit, and should use as many as possible (i.e. use the fastest clock supported such as 40Mhz, and a prescaler of 1 when possible). But as also previously stated, it is also recommended that all nodes on the bus should have the same timing settings, so this may also need to be considered.

    Any guidance on configuring this part for 2, 4, 5, or 8 Mb/s would be helpful.

    I would suggest you go through the exercise of calculating these values yourself based on the examples in the TCAN4550-Q1’s Software User’s Guide to get a better feel and understanding of the settings, but here are some general recommendations that can be used as a starting point in your evaluation.

    Clock Frequency MHz

    Bit Rate (Mbps)

    Primary Sample Point %

    Secondary Sample Point %

    Baud Rate Prescaler

    Tq (Time Quanta) per bit

    Phase_Seg1

    Phase_Seg2

    SJW

     

    TDC (Yes/No)

    TDC Offset

    40

    2

    80

    80

    1

    20

    15

    4

    4

    Yes

    16

    40

    4

    80

    80

    1

    10

    7

    2

    2

    Yes

    8

    40

    5

    75

    75

    1

    8

    5

    2

    2

    Yes

    6

    40

    8

    80

    80

    1

    5

    3

    1

    1

    Yes

    4

    Also note that some of the register fields will interpret the value input as 1 greater than the number entered because zero is an invalid entry. The values I have given you in the above table are the actual numbers, therefore you may need to enter 1 less in the DBTP register as noted in the datasheet.

    Thanks much to anyone who can help!

    I hope I have addressed all of your questions with enough detail for you to understand. But if you have any follow up questions, or still need have question on any of these topics, please let me know.

    Regards,

    Jonathan

  • Thank you so much for your detailed reply.  This was extremely helpful. I have been going over it carefully, and I have a few more questions.

    I was referencing this CAN FD spec:
    can-newsletter.org/.../e5740b7b5781b8960f55efcc2b93edf8.pdf
    which is a file called can_fd_spec.pdf and is version 1.0.  The link you provided has a number of files, but nothing that looks like this specification.  Is there a more recent version of the spec than 1.0?  Where would I find that?  The documents from the Bosch site you reference all refer to version 1.0 of the specification.  I could not find this document on the https://www.can-cia.org/ website, but perhaps it has a different name for me to search and it looks like some of the documents require becoming a member which costs at least 700 Euros.

    This document states on page 29 that the SYNC_SEG is 1 Tq for both nominal and data bit rates, and the PROP_SEG, PHASE_SEG1 and PHASE_SEG2 for nominal may be 1 to 32 (or more), while for data they may only be 1 to 8.  It says SEG2 = max(SEG1, IPT) and IPT <= 2.  I took this to mean the worst case for IPT is 2, so SEG2 >= 2 to always meet the spec, but I see in the MCAN User's Manual, they explicitly say IPT = 0. Also, it says the DTSEG1 and DTSEG2 fields may be zero, so the minimum possible for these is 1 Tq, as you said. Interestingly, the NTSEG1 and NTSEG1 fields must be at least 1 and the segment length is one more than the field, so the minimum possible is 2 Tq.  The DTSEG1 fiels is 5 bits, so the part supports a maximum of 32 Tq as you said, but the DTSEG2 field is only 4 bits, for a maximum of 16.  There are a few errors in the table of the data sheet describing register 0x100C:

    DSJW is shown as 4 bits but the bit column shows it as 3 bits.  I assume 4 bits is correct?
    The description for DTSEG2 says "Data time Segment before sample point", same as the description for DTSEG1, but it should say *after* the sample point.  Correct?

    To meet the maximum of 8 for data segments, the prescaler needs to be increased for lower data rates.  If I use a prescaler of 1 with a 40 MHz crystal for data rates < 1.6 MHz, this specification will not be met.  The user's manual allows SEG2 up to 16 Tq.  Should that be considered the definitive specification?  Please keep in mind, my application will be interfacing to other hardware so I need the most compatible implementation.

    Please look at the CAN FD spec I referenced, pages 28-33.  It has a lot more detail on how to calculate the various phases of a bit time than a simple rule of thumb to set the sample point at 80%.  The choice of sample point will affect the maximum allowable cable length.  For example, on page 28, it states:
    PROPAGATION TIME SEGMENT (PROP_SEG)
    This part of the bit time is used to compensate for the physical delay times within the
    network. It is twice the sum of the signal’s propagation time on the bus line, the input
    comparator delay, and the output driver delay.

    From the data sheet, the worst case propagation delay times for the TX driver are 110ns and for the RX receiver is 90ns, so RX + TX <= 200ns.

    Please help me understand why I do not need to try to meet the requirements spelled out in the CAN FD spec I referenced regarding the PROP_SEG length.  It says PROP_SEG must be at least 200ns with this part, even with a 0 length cable. (I think they actually mean 1x the driver delays + 2x the propagation delay, not twice the sum.)

    Thank you for clarifying the internal/external timestamp counter.  I want to use the external counter for my application, but Icannot get either to count at a clock rate that makes sense.  It is not clear from any of the documents or your answer.  The user's manual simply says it is clocked at the "bit time", but both the nominal rate and the data rate are called "bit time".  I would hope that the internal counter counts at the nominal rate always, as you suggest.  Is there somewhere in the documents that verifies this?

    You said that register 0x804 sets the prescaler for the external counter.  The tcan4550-q1 data sheet for this register timestamp prescaler field says "Writing to this register resets the internal timestamp counter to 0 and will set the internal CAN clock divider used for MCAN Timestamp generation to (Timestamp Prescalar x 8)".  This seems to be an error in the datasheet.  And it should also say that the input to this divider is the 40 MHz oscillator.  Is that correct?

    Also, your answer (and the data sheet) suggests that I could choose either timestamp, internal or external, but this comment is in the sample code:
    // Configure the Timestamp counter to use an external time stamp value. This is required to use time stamps with CAN FD
    Is this true that timestamps must be set to external?  Does this comment mean only if FD mode is enabled or always with this part?  Or, is this comment incorrect?  I tried both the internal and external counters and they both seem to work.

    Here is the code from the example that I was asking about:

    bool
    TCAN4x5x_MCAN_EnableProtectedRegisters(void)
    {
        uint8_t i;
        uint32_t readValue, firstRead;

        firstRead = AHB_READ_32(REG_MCAN_CCCR);
        if ((firstRead & (REG_BITS_MCAN_CCCR_CCE | REG_BITS_MCAN_CCCR_INIT)) == (REG_BITS_MCAN_CCCR_CCE | REG_BITS_MCAN_CCCR_INIT))
            return true;

        // Unset the CSA and CSR bits since those will be set if we're in standby mode. Writing a 1 to these bits will force a clock stop event and prevent the return to normal mode
        firstRead &= ~(REG_BITS_MCAN_CCCR_CSA | REG_BITS_MCAN_CCCR_CSR | REG_BITS_MCAN_CCCR_CCE | REG_BITS_MCAN_CCCR_INIT);
        // Try up to 5 times to set the CCCR register, if not, then fail config, since we need these bits set to configure the device.
        for (i = 5; i > 0; i--)
        {
            AHB_WRITE_32(REG_MCAN_CCCR, firstRead | REG_BITS_MCAN_CCCR_CCE | REG_BITS_MCAN_CCCR_INIT);
            readValue = AHB_READ_32(REG_MCAN_CCCR);

            if ((readValue & (REG_BITS_MCAN_CCCR_CCE | REG_BITS_MCAN_CCCR_INIT)) == (REG_BITS_MCAN_CCCR_CCE | REG_BITS_MCAN_CCCR_INIT))
                return true;
            else if (i == 1)        // Ran out of tries, give up
                return false;
        }
        return true;
    }

    You can see it tries to write to the register 5 times.  From your description, it sounds like 2 writes should be sufficient for this routine.  Is that correct?

    Regarding remote frames: I need to support both standard and FD modes.  I do not need to implement automatic transmission, but I do need to receive remote frame packets.  If I set RRFE and RRFS to 0, will I receive remote frames?

    If I configure the TCAN4550 for, say, FD at 500k/2M and I connect it to a standard CAN bus at 500k, it should work, correct?  Are there any gotchas doing this?

    Thank you again for your help with this,


    Edwin

  • Hi Edwin,

    Once again I have interleaved my responses into your questions to make it more clear which question I am attempting to answer since there are many. I’ve made your questions Bold to help distinguish them from my response.

    I was referencing this CAN FD spec:
    can-newsletter.org/.../e5740b7b5781b8960f55efcc2b93edf8.pdf
    which is a file called can_fd_spec.pdf and is version 1.0.  The link you provided has a number of files, but nothing that looks like this specification.  Is there a more recent version of the spec than 1.0?  Where would I find that?  The documents from the Bosch site you reference all refer to version 1.0 of the specification.  I could not find this document on the https://www.can-cia.org/ website, but perhaps it has a different name for me to search and it looks like some of the documents require becoming a member which costs at least 700 Euros.

    Thanks for the link. Bosch created the CAN FD protocol in 2012 and this was the first version of specification for this enhanced CAN protocol that added a flexible or faster data bit time as compared to the nominal or arbitration bit time.

    Unfortunately the CAN FD spec you are referencing is a dated document and the current CAN FD specifications are handled in the ISO 11898-x family of documents overseen by CAN in Automation, but they are official ISO publications. They information is broken into multiple parts that are separate documents, but primarily the -1 and -2 parts are of most relevance and can be purchased at the below links.

    ISO 11898-1:2015 (contains more of the protocol information)

    https://www.iso.org/standard/63648.html

    ISO 11898-2:2016 (contains more of the Physical Layer voltage and timing information)

    https://www.iso.org/standard/67244.html

    There is also another specification held by SAE International that you will also see mentioned in places that is SAE J2284-5 that is mostly compatible with the ISO 11898 specs, but has a few differing parameters. The ISO 11898 is more commonly referenced, but the SAE J2284-5 can be purchased at the below link.

    https://www.sae.org/standards/content/j2284/5_201609/

    This document states on page 29 that the SYNC_SEG is 1 Tq for both nominal and data bit rates, and the PROP_SEG, PHASE_SEG1 and PHASE_SEG2 for nominal may be 1 to 32 (or more), while for data they may only be 1 to 8.  It says SEG2 = max(SEG1, IPT) and IPT <= 2.  I took this to mean the worst case for IPT is 2, so SEG2 >= 2 to always meet the spec, but I see in the MCAN User's Manual, they explicitly say IPT = 0. Also, it says the DTSEG1 and DTSEG2 fields may be zero, so the minimum possible for these is 1 Tq, as you said. Interestingly, the NTSEG1 and NTSEG1 fields must be at least 1 and the segment length is one more than the field, so the minimum possible is 2 Tq.  The DTSEG1 fiels is 5 bits, so the part supports a maximum of 32 Tq as you said, but the DTSEG2 field is only 4 bits, for a maximum of 16. 

    The various segment time quanta values in the 2012 Bosch CAN FD document are outdated and you should use the values published in the TCAN4550 and M_CAN documents. I believe the original values (such as the data range of 1 to 8) are now considered minimum values and they are listed as “Minimum configuration ranges” in the ISO 11898-1:2015.

    The Sync_Seg is always 1 Tq for both the Nominal and Data bit times using their respective Tq values.

    The Prop_Seg is the propagation time segment of the bit and is used to compensate for physical delay times in the system consisting of the signal propagation time on the bus and internal delay times of the CAN nodes. The M_CAN controller doesn’t have a specific register value field for the Prop_Seg and instead lumps it in with the Phase_Seg1 to create a combined time before the sample point value. Also, in CAN FD, the Prop_Seg is only relevant in the Arbitration portion of the Nominal Bit Time or when the device is used to send a Classical or Non-FD message frame. The prop seg is not used in an FD data bit and this has been replaced with the transmitter delay compensation.

    Phase_Seg1 and Phase_Seg2 buffer segments are used to compensate for phase errors resulting from a variety of sources including Tq width mismatch resulting from the slightly different clock frequencies on the two nodes. The CAN Controller will look for edge transitions on specific bits that are defined to be a fixed value in all message frames and it uses to determine the amount of phase error between the signal and where it thinks the signal should be. It will then use this information to resynchronize to the signal so that it can sample the bits in the correct information. Each of these segments must be at least 1 Tq.

    The Sample Point lies between the Phase_Seg1 and Phase_Seg2.

    The Information Processing Time is the number of Tq required for the CAN controller to calculate the subsequent bit level at the Sample Point. This must occur before the end of Phase_Seg2 which is also the end of the Data Portion of the message. This is now defined simply as less than or equal to the Phase_Seg2. In the case of M_CAN, this is instantaneous and therefore they specify it as IPT = 0.

    The allowed bit timing configuration ranges supported by the M_CAN IP is as follows:

    Phase

    Segments

    Min

    Max

    Unit

    Arbitration

    Phase_Seg1+Prop

    2

    256

    Time Quanta

    Arbitration

    Phaase_Seg2

    2

    128

    Time Quanta

    Arbitration

    SJW

    1

    128

    Time Quanta

    Arbitration

    Bit Duration

    5

    385

    Time Quanta

     

    Phase

    Segments

    Min

    Max

    Unit

    Data

    Phase_Seg1+Prop

    1

    32

    Time Quanta

    Data

    Phaase_Seg2

    1

    16

    Time Quanta

    Data

    SJW

    1

    16

    Time Quanta

    Data

    TDC Offset

    0

    127

    CAN_Clk cycles = minimum Time Quanta (mtq)

    Data

    Bit Duration

    4

    49

    Time Quanta

    There are a few errors in the table of the data sheet describing register 0x100C:
    DSJW is shown as 4 bits but the bit column shows it as 3 bits.  I assume 4 bits is correct?
    The description for DTSEG2 says "Data time Segment before sample point", same as the description for DTSEG1, but it should say *after* the sample point.  Correct?

    Yes, the DSJW[3:0] is the correct value and there are 4 bits in this field. You are also correct on the correct description for the DTSEG2[3:0] field and it should say *after*. Thank you for pointing out the typos.

    To meet the maximum of 8 for data segments, the prescaler needs to be increased for lower data rates.  If I use a prescaler of 1 with a 40 MHz crystal for data rates < 1.6 MHz, this specification will not be met.  The user's manual allows SEG2 up to 16 Tq.  Should that be considered the definitive specification?  Please keep in mind, my application will be interfacing to other hardware so I need the most compatible implementation.

    Yes, use the numbers published in the TCAN4550 and M_CAN documents as this is definitive for the device. The original maximum of 8 is now considered the minimum value for a maximum value, or rather that the maximum value could be greater than 8 if the hardware supports a larger value. This basically means that the M_CAN will support a finer Time Quanta resolution than was originally specified. Also note that the Bosch also developed M_CAN, so the newer M_CAN documents should always be given preference over the older 2012 spec. With that said you should be able to support a minimum data rate of 0.83 Mbps with a 40MHz crystal and a prescaler of 1. If you need to support 0.5 Mbps then you will need to increase the prescaler to 2.

    Please look at the CAN FD spec I referenced, pages 28-33.  It has a lot more detail on how to calculate the various phases of a bit time than a simple rule of thumb to set the sample point at 80%.  The choice of sample point will affect the maximum allowable cable length.  For example, on page 28, it states:
    PROPAGATION TIME SEGMENT (PROP_SEG)
    This part of the bit time is used to compensate for the physical delay times within the
    network. It is twice the sum of the signal’s propagation time on the bus line, the input
    comparator delay, and the output driver delay.

    From the data sheet, the worst case propagation delay times for the TX driver are 110ns and for the RX receiver is 90ns, so RX + TX <= 200ns.

    Please help me understand why I do not need to try to meet the requirements spelled out in the CAN FD spec I referenced regarding the PROP_SEG length.  It says PROP_SEG must be at least 200ns with this part, even with a 0 length cable. (I think they actually mean 1x the driver delays + 2x the propagation delay, not twice the sum.)

    I’m sorry if I wasn’t clear in my last post. The Prop_Seg is only part of the Arbitration portion of a CAN FD message which has a maximum bit rate of 1 Mbps and therefore it is not relevant in the context of a FD data bit rate. The Prop_Seg is an important component of successful Arbitration. This is because in CAN each node could claim control of the bus if the message it is trying to transmit has the lowest ID value corresponding to the highest priority. During this phase multiple nodes can attempt to transmit their message and sample the bit they transmit to determine if another node has a higher priority message. If a higher priority message is detected from a different node on the bus, the lower priority node must stop transmitting and yield the bus to the other node before it can try again.

    In order for this to work, the worst case propagation delay between the farthest nodes on the bus must be offset before the device tries to sample the bit. The Prop_Seg would consist of the total delay between the devices which includes the tx delay, twice the propagation delay along the wires, and rx delay on the other node.

    I think your question is why twice the propagation delay along the wires used, and this is because of the delay in what I’ll call “absolute time” created through synchronization. When a different node receives a message it will use the Sync_Seg and try to adjust its timing to match the timing of the bits it is receiving to ensure accurate sampling. However, if the node that transmitted first (let’s call it Node 1) was at the far end of the bus, then the receiving node (Node 2) receives the Sync_Seg after one propagation delay time of the bus. Node 2 then resets it’s timing to that point in time which is now “offset” from Node 1’s timing that I am calling “absolute timing” and the original transmitting Node 1 is still working off of the absolute time or original time reference it used.

    Therefore the response bits transmitted from Node 2 already have 1x the propagation delay of the wires embedded in its timing and if it transmitted back to Node1 with a message during arbitration, Node 1 won’t receive the bits from Node 2 until those bits propagated along the wires again. This means that there is a worst case propagation delay along the wires of 2x the single trip delay. Then the delays for the transceivers are simply added on their own.

    It is generally assumed for calculation purposes that the Nominal Bit Time setting contains an extra Prop_Seg that is simply added to the total time before the sample point and is essentially a fixed delay. This ensures all nodes on the bus will be sampling the bit at a time when it is ensured the values from all the nodes can be seen.

    However, during the FD Data phase, the arbitration phase is over and only a single node is still transmitting. This is at the heart of the CAN FD protocol. Since there is no longer a need to have this extra delay in the bit period and all other nodes on the bus are simply receiving the data being transmitted and will receive this data as it arrives naturally. Therefore the bit rate can be increased significantly during this portion.

    But it is because of the Arbitration in CAN that the nominal bit rate time can’t be increased beyond 1 Mbps because the bit time becomes too small for the arbitration to complete unless the bus is very short and the loop delays in the transceiver are very small.

    But during the FD data phase, the need for error checking the data still exists and the transmitting node must still sample the bits it is sending to ensure the value on the bus as seen through the RX signal path matches the TX data. This is where the Transmitter Delay Compensation comes into play and is used during the Data phase of a CAN FD message frame. However, it is not the same as the Prop_Seg.

    I hope this is more clear. You still need to meet the Prop_Seg requirements as you have stated, but only in context of the arbitration data rate. Therefore if you add up the TX and RX delays for the nodes and add to that the propagation delay of the wiring harness, you should get the prop delay for the bus. If you have a long bus, then you will need to use a slower arbitration data rate to ensure the delay is less than the bit time and the bits can be sampled properly. If you are unable to use a slower arbitration bit rate, then you must shorten the wiring harness or use different transceivers with shorter delay times until the specification can be satisfied.

    Thank you for clarifying the internal/external timestamp counter.  I want to use the external counter for my application, but Icannot get either to count at a clock rate that makes sense.  It is not clear from any of the documents or your answer.  The user's manual simply says it is clocked at the "bit time", but both the nominal rate and the data rate are called "bit time".  I would hope that the internal counter counts at the nominal rate always, as you suggest.  Is there somewhere in the documents that verifies this?

    You said that register 0x804 sets the prescaler for the external counter.  The tcan4550-q1 data sheet for this register timestamp prescaler field says "Writing to this register resets the internal timestamp counter to 0 and will set the internal CAN clock divider used for MCAN Timestamp generation to (Timestamp Prescalar x 8)".  This seems to be an error in the datasheet.  And it should also say that the input to this divider is the 40 MHz oscillator.  Is that correct?

    Ok, the external timestamp counter in the TCAN4550 counts clock cycles for the 40Mhz input clock. A prescaler for this external timestamp counter is set in register 0x0804. By default it is set to a value of divide by 16 when the timestamp prescaler register is set to 0x2. The calculation is “Timestamp Prescaler” x 8 = 2 x 8 = 16.

    Once again there is poor language used in this field description and it states that it will “set the internal CAN clock divider used for MCAN Timestamp generation”. The reference of “internal” in this case means that the timestamp counter is internal to the TCAN4550 device and not supplied to the chip externally. I have previously discovered this dual use of the “internal” term and this unfortunately is not consistent with the “internal” terminology used to reference the “internal” counter inside of the M_CAN core. The timestamp prescaler set in register 0x0804 actually sets the divider for the counter that is “external” to M_CAN.

    This situation is due to combining documentation from multiple individuals with different perspectives on what was considered “internal”. One considered any signals generated inside the device and not provided through external device pins as “internal” and the other was following the M_CAN language of “internal to M_CAN.”

    So to use the External Counter that counts clock cycles you will need to do the following.

    Set the TSS[1:0] bits in the Timestamp Counter Configuration Register 0x1020 (M_CAN register) to 2’b10 – External timestamp counter value used. This will tell M_CAN to use the counter that counts clock cycles.

    Set the Timestamp Prescaler to the desired value based. Every time you “write” to this register, it will clear the external timestamp counter value and reset it to zero. Therefore, whenever you want to reset it, simply re-write the desired prescaler value. I would think that this would typically be done at the end of the initialization sequence or some other known event so that the timestamp counter has a meaningful count value in the system.

    Once again, the counter value can be read through register 0x1024 which returns the value of whichever timestamp counter that is configured.

    If you later decide to use the “internal” counter that counts bit times, you only need to configure the TSS[1:0] field to 2’b01 in register 0x1020. The prescaler for this counter is set through TCP[3:0] of the same register 0x1020 except instead of dividing down the clock cycles, it will divides down multiples of CAN bit times which is based off of the NBTP register settings.

    Reading register 0x1024 will return the counter value, and writing to register 0x1024 (any value) will reset the counter to zero.

    I hope this is clear and I apologize for the poor documentation in the datasheet for this feature. I agree it is rather confusing.

    Also, your answer (and the data sheet) suggests that I could choose either timestamp, internal or external, but this comment is in the sample code:
    // Configure the Timestamp counter to use an external time stamp value. This is required to use time stamps with CAN FD
    Is this true that timestamps must be set to external?  Does this comment mean only if FD mode is enabled or always with this part?  Or, is this comment incorrect?  I tried both the internal and external counters and they both seem to work.

    With no intended disrespect to my colleague that developed the reference code, I do not agree with the comment he added in the code about the timestamp counter in that it “must” be set to the external counter. Either of the counters can be used, and both are available for you to use. I think what was intended by this comment is that a timestamp counter should be used so that the message can be timestamped. Since the code can only set one, his preference was the external since it was a more straightforward calculation. There may be a system requirement on which one should be used if other nodes will need to use or understand the timestamp values in order for some consistency. But otherwise I can’t think of any reason why one should be preferred over the other.

    Here is the code from the example that I was asking about:

    bool
    TCAN4x5x_MCAN_EnableProtectedRegisters(void)
    {
        uint8_t i;
        uint32_t readValue, firstRead;

        firstRead = AHB_READ_32(REG_MCAN_CCCR);
        if ((firstRead & (REG_BITS_MCAN_CCCR_CCE | REG_BITS_MCAN_CCCR_INIT)) == (REG_BITS_MCAN_CCCR_CCE | REG_BITS_MCAN_CCCR_INIT))
            return true;

        // Unset the CSA and CSR bits since those will be set if we're in standby mode. Writing a 1 to these bits will force a clock stop event and prevent the return to normal mode
        firstRead &= ~(REG_BITS_MCAN_CCCR_CSA | REG_BITS_MCAN_CCCR_CSR | REG_BITS_MCAN_CCCR_CCE | REG_BITS_MCAN_CCCR_INIT);
        // Try up to 5 times to set the CCCR register, if not, then fail config, since we need these bits set to configure the device.
        for (i = 5; i > 0; i--)
        {
            AHB_WRITE_32(REG_MCAN_CCCR, firstRead | REG_BITS_MCAN_CCCR_CCE | REG_BITS_MCAN_CCCR_INIT);
            readValue = AHB_READ_32(REG_MCAN_CCCR);

            if ((readValue & (REG_BITS_MCAN_CCCR_CCE | REG_BITS_MCAN_CCCR_INIT)) == (REG_BITS_MCAN_CCCR_CCE | REG_BITS_MCAN_CCCR_INIT))
                return true;
            else if (i == 1)        // Ran out of tries, give up
                return false;
        }
        return true;
    }

    You can see it tries to write to the register 5 times.  From your description, it sounds like 2 writes should be sufficient for this routine.  Is that correct?

    Yes, 2 times should suffice for setting the INIT and CCE bits, but I believe 5 was chosen to allow for some margin or other factors to scrap an attempt before aborting the procedure. Other protected bits in the CCCR may or may not take on the second write and a third write may be needed for those bits. The key point is that you will need to at least write twice if you are not monitoring the register and preferably include a read verify routine in the function to ensure it has properly been set before writing to any protected bits in other registers. If the INIT and CCE bits are not set properly, all the other writes will not take but without a read verify routine, you would never know.

    Regarding remote frames: I need to support both standard and FD modes.  I do not need to implement automatic transmission, but I do need to receive remote frame packets.  If I set RRFE and RRFS to 0, will I receive remote frames?

    Yes you will receive remote frames, but you will not be able to automatically transmit a message as I have previously described.

    If I configure the TCAN4550 for, say, FD at 500k/2M and I connect it to a standard CAN bus at 500k, it should work, correct?  Are there any gotchas doing this?

    Yes, there is a gotcha, and that is you can’t mix a CAN FD and CAN buses because if you transmit a CAN FD message on a standard CAN bus, every non-FD node will throw an error flag at the FD message. You can use CAN FD nodes for classical CAN applications but you can’t use classical CAN nodes for CAN FD.

    BUT, if you only sent standard (non-FD) messages from the CAN FD capable node where the FDF and BRS bits in the message header are set to ‘0’ then you can use the CAN FD capable transceiver in a classical or standard CAN bus. In this case if I knew that CAN FD was not supported, I would personally configure the data rate to the same 500k as the arbitration. If the FDF and BRS bits get set, there will be a protocol error, but the standard nodes will have an easier time handling the error that getting hit with the FD rate it would never be expecting. But I can’t think of a reason why this would be required and as long as the FDF and BRS bits are never set to ‘1’ in which case the DBTP settings should be irrelevant.

    I hope this is clear and informative.

    Regards,

    Jonathan

  • Jonathan, you are awesome!  I can't tell you how much I appreciate your clear and detailed answers to my questions.  I have my system up and working, and passing all my tests so far.  There's still lots to do in the project, but I have the basics working.  Thank you so much!

    If I might trouble you for one more thing, you answered my question about settings for 2,4,5,8 Mb/s.  If you have this information for the other data rates I need to support, that would help me fill in my table.  These rates are:

    250kb/s, 500kb/s, 800kb/s, 1Mb/s

    Again, thank you so much for your responses.

    Edwin

  • Hi Edwin,

    Thanks! I'm glad I could help you work through the setup and configuration of the TCAN4550.

    I have updated the table I have previously provided to include suggested settings for the other data rates you have asked about. I have tried these settings on my test network and they work, but adjustments may need to be made to accommodate different systems. I will also note, that the Arbitration rate (NBTP settings) must always be less than or equal to the Data rate (DBTP settings). Therefore, if you have a 500kbps Arbitration rate, you can’t have a 250kbps Data rate. In this case you would need to also set the Arbitration rate to 250kbps.

    Clock Frequency MHz

    Bit Rate (Mbps)

    Primary Sample Point %

    Secondary Sample Point %

    Baud Rate Prescaler

    Tq (Time Quanta) per bit

    Phase_Seg1

    Phase_Seg2

    SJW

     

    TDC (Yes/No)

    TDC Offset

    40

    0.25

    80

    79.4

    4

    40

    31

    8

    8

    Yes

    127

    40

    0.5

    80

    80

    2

    40

    31

    8

    8

    Yes

    64

    40

    0.8

    80

    80

    2

    25

    19

    5

    5

    Yes

    40

    40

    1

    80

    80

    1

    40

    31

    8

    8

    Yes

    32

    40

    2

    80

    80

    1

    20

    15

    4

    4

    Yes

    16

    40

    4

    80

    80

    1

    10

    7

    2

    2

    Yes

    8

    40

    5

    75

    75

    1

    8

    5

    2

    2

    Yes

    6

    40

    8

    80

    80

    1

    5

    3

    1

    1

    Yes

    4

    Good luck with the rest of your testing. If you have any additional questions, feel free to reach back out on this forum.

    Regards,

    Jonathan