CAN: Tx Delay Compensation is not working

[Elmue]

Hello

I am trying to get the STMN32G431 processor to do what I want.
If I set the baudrates 500kB / 2MB and a samplepoint of 87.5% for both and send a CAN packet with FDF and BRS I get after 3 ms:
LastError = Recessive Bit Error and 8 Tx errors

and 2 ms later:
LastError = Recessive Bit Error,  248 Tx errors and Bus OFF !
Sometimes it is also a Dominant Bit Error.

This happens even in Internal loopback mode!
Therefore I set a Tx delay compensation of zero.
But also with other values for Tx delay compensation, it never works.

If I chose the samplepoint up to 85% all is still fine.
But with 87.5% I get a BusOff which is 100% reproducable.

Now comes the strange thing:

HAL_FDCAN_ConfigTxDelayCompensation(&can_handle, 0, 0);
HAL_FDCAN_EnableTxDelayCompensation(&can_handle);

will produce this problem, but with

HAL_FDCAN_DisableTxDelayCompensation(&can_handle);

it suddenly works correctly!

How is it possible that setting a delay of zero is not the same as a delay that is turned off?

Here my settings:
Clock 160 MHz

Nominal baudrate prescaler: 2
Segment 1 = 139
Segment 2 = 20
JSW = 8

Data baudrate prescaler: 5
Segment 1 = 13
Segment 2 = 2
JSW = 1
_____________________

Where can I find a documentation that explains in detail how to calculate the two values that I must pass to
HAL_FDCAN_ConfigTxDelayCompensation ?

I have been googling the whole day now and I have read the existing sparse documentation from ST and I still have absolutely no clue which values to pass to HAL_FDCAN_ConfigTxDelayCompensation ?

And as this compensates a hardware delay I also don't understand why must we not simply specify a fix delay in nanoseconds ?

If the CAN driver chip has a fix delay of 60 ns, I would expect a configuration where I enter 60 ns and that's it.
Why is this so complicated ?
And why is there no documentation how to calculate the values for offset and filter?

I found a posting that says to set the filter to zero and the offset to DataPrescaler * DataTimeSeg1.
But this does not work for 87.5%.
And it does not make sense to me.
The chip does not care about data segment 1.
The CAN bus transceiver chip has a fix hardware delay that never changes.
I would understand to calculate this delay from the clock frequency, but why from segment 1 ?

Can anybody explain me this in detail please?

[MHoll.2]

The sample poin in the data phase is normaly set different then the sample point in the Arbitration phase (at about 50..70%). Also it is better to use the same prescaler for Arbitration and Data phase. Please read:

https://www.bosch-semiconductors.com/media/ip_modules/pdf_2/papers/icc14_2013_paper_hartwich_1.pdf

and

https://www.can-cia.org/fileadmin/cia/documents/publications/cnlm/march_2018/18-1_p28_recommendation_for_the_canfd_bit-timing_holger_zeltwanger_cia.pdf

[mƎALLEm]

Hello,

1- Please watch this video on ST Youtube channel: FDCAN Normal Operating Mode

2- Use Kvaser online tool for FDCAN bit time computation. As said by @MHoll.2 , the sample point in data phase is not as for the arbitration phase and it tends to be in the middle of the bit instead of the end of it like with the arbitration phase (you can verify that using Kvaser tool).

3- You can also refer to this article as it may help you: STM32 FDCAN running at 8 Mb/s on NUCLEO boards

[LCE]

Probably by simply turning delay compensation on, there is a minimum delay in the used HW.

And in case of doubt, always check what the HAL functions actually do.

If the project is not just for hobby, you should know 100% what's going on.

[Elmue]

Hello MHoll
Thanks for the links. They are very good documents.

Hello mƎALLEm
This video did not tell me anything that I did not know before.

Hello LCE
Obvisously I studied HAL_FDCAN_ConfigTxDelayCompensation(). It only loads the register TDCR.
What do you expect me to see there ?

Sadly nobody has given me not even a rudimentary answer to my questions.

1.)
I asked how to calculate the values TdcOffset and TdcFilter to be passed to HAL_FDCAN_ConfigTxDelayCompensation()

2.)
I also asked for an explanation of the strange formula
TdcOffset = DataPrescaler * DataTimeSeg1
which is recommended here in this forum in other places.
3.)
I also asked why setting a zero offset has not the same effect as turning compensation off.

MHoll is listed here as "Senior III" and mEALLEm as "ST Employee".
If ST gives us only a very abstract documentation and not even the employees of ST are able to answer this practical question, how can we write a correctly working firmware?

How do I calculate the two values to be passed to HAL_FDCAN_ConfigTxDelayCompensation() ?
Are there no engineers in ST who developed this processor, whom you can ask to give a useful answer?

LCE:
> If the project is not just for hobby, you should know 100% what's going on.

You did not provide any useful information that would help me to "know 100% what is going on"!

[LCE]

> You did not provide any useful information that would help me to "know 100% what is going on"!

Do not trust HAL blindly. If using HAL, go through each function and understand what and how it's done there.

I recently "played" with TDC with my hardware (H733, transceiver ADM3058E with a max Loop Propagation Delay of 155 ns).
I found that at 8 Mbps it worked with a TDC value from 4 up to 10, with a Time Quantum 'mtq' = 12.50 ns.
So that's a range from 50 ns to 125 ns.

If your mtq is fixed (should be), there's no need for calculation, just assign it a constant value depending on your transceiver's delay. And as you see above, there's quite a bit of "headroom".

Play with it.

And then maybe grab some ice spray and a blow-dryer to test it over a higher temperature range. :D

[mƎALLEm]

---

@Elmue wrote:

MHoll is listed here as "Senior III" and mEALLEm as "ST Employee".
If ST gives us only a very abstract documentation and not even the employees of ST are able to answer this practical question, how can we write a correctly working firmware?

---

1- In the community, we are supporting hundreds of users per day and we are not providing peer to peer support for each user. If you need more specific questions and you are not satisfied by the answers provided in the community you can file your question over this link, or contact your local FAE, they can assist you in deep. 

2- As ST employee I'm providing answers as I can and, in this community, ST employees are not obliged to provide the exact answers, but we can assist you or guide you to right way.

Thank you for your understanding.

[Elmue]

Hello LCE

> Do not trust HAL blindly. If using HAL,

I dont understand what you mean with "trust blindly" ? I study the code and see what it does.
Is this trusting blindly?

> go through each function and understand what and how it's done there.

As I already wrote HAL_FDCAN_ConfigTxDelayCompensation() does nothing more than loading the register TDCR. What do I need to understand additionally to this ?

> If your mtq is fixed (should be), there's no need for calculation, just assign it a constant value depending on your transceiver's delay

In this case it would be easy.
But I'am writing a new firmware for the CANable where the user can set any baudrate.
So I need a way to calculate this value dynamically.
And as the Offset value TDCO is specified in multiples of Time Quantums it surely depends on the baudrate.

> I recently "played" with TDC with my hardware

If I "play" with all possible baudrates I will never finish this work. There must be any formula to calculate this.
I tried with 2 different CANable boards and they behave very different, although both are new and from the same vendor.

And if the compensation does not even work as expected in internal loopback mode, how will it work with a real hardware loopback?

The problem is that ST gives us such a bad quality documentation that we must post questions here and still we never get a useful answer because the employees themself don't know the answer and they are not willing to ask a colleague in their own company! That is really a shame.

This processor is a black box for us.
I cannot program a blackbox without a useful documentation and a non-existing support.

[LCE]

Sorry for trying to help! ;)

> I study the code and see what it does. Is this trusting blindly?

No.

> And if the compensation does not even work as expected in internal loopback mode,
> how will it work with a real hardware loopback?

"Internal" is the keyword here, so the external transceiver is not used, and TDC can make things only worse - but I'm not sure what's recommended by ST (maybe a minimal TDC? I guess not).
So better test TDC with an external transceiver.

Documentation is not great, but also not that bad, otherwise the majority of users wouldn't have it working.

[Elmue]

Hello LCE

> Documentation is not great, but also not that bad, otherwise the majority of users wouldn't have it working.

The majority surely does not write a generic firmware that must work with multiple baudrates as I do.
The majority works in the automotive industry where they have a processor and a fix transceiver chip in an ECU.
They play around with the values until they find one that works and don't care anymore about it.
If you have always the same transceiver chip and use only one baudrate you can find these values by experimenting.
But I cannot do this because I write a generic firmware that must be configurable for multiple baudrates and must be configurable for different transceiver delays.
I don't even know since which baudrate to start enabling delay compensation ?
In some code that I found on Github they enable it at 1 Mbaud, in another code they enable it at 2.5 Mbaud.

Documentation is definitely very bad.
Did you find anything about the second parameter to pass to HAL_FDCAN_ConfigTxDelayCompensation ?
All documentation is only abstract theoretical.
No sample code, nor formulas, nothing useful.
And the comments in the HAL code are extremely sparse.

__________________________________

Hello MELLAEM

> you can file your question over this link, or contact your local FAE, they can assist you in deep. 

I created a case and got an answer.
But it is as useless as this forum.
The answer that I got was to read the chapter "Transceiver Delay Compensation" in the reference manual which I already had read 3 times before posting here.

I clearly see that in the entire company ST there is nobody who deeply understands the processors that they sell.

The chip is not working correctly.
I would say that the chip has design errors.
How is it possible that setting a delay of zero is not the same as turning off the delay ?

And the documents say that the processor measures the delay and stores it in register TDCV after sending a packet.
But I can send packets with different baudrates and this register is always zero.
Did you ever see a value greater than zero in TDCV ?