FDCAN with STM32H735

[alex31]

Hello,

I have backported trunk fdcan to stable, and so far, it works both for fdcanV2 (using watermark) and fdcanV1 (using new message IT)

1) I want to submit trivial patch to add TDCR (transmit delay register) to configuration structure : when using FDCAN at high baudate, it make transmission way more reliable.

To enable TDC, one has to :
1/ setting FDCAN_CONFIG_DBTP_TDC bit in DBTP register
2/ setting TDCR register (there is advice in reference manual to calculate the two fields TDCO and TDCF)

2) when not all the nodes on the bus are powered at the same time, first node try to send and nobody answer, no this first node retransmit frame for a while until it gives up, going offline. There is way to detect this situation : if canTransmitTimeout return with a timout condition, and FDCAN_CCCR_INIT is set in the CCCR register.
restoring the node online is done when resetting FDCAN_CCCR_INIT bit in CCCR register.

would be nice to have an abstracted way to test if node is offline, and to set it online again.

3) is it possible to backport hdcan driver in stable ?

Thanks
Alexandre

[Giovanni]

Hi,

The whole HAL will be back-ported to 21.x stable before next release, will handle the patch.

Giovanni

[alex31]

Hello, one mode proposal for a patch to manage bus offline recovery.

When a canbus peripheral send a frame that does not receive ACK, it automatically retransmit for a while, until peripheral itself goes offline.
This occurs each time all the agents on a bus are not powered synchronously.

Peripheral stay offline until application resume it online.

This patch for FDCANv1 and FDCANv2 add the BOE IT source to get interrupted when CANFD goes offline. It add CAN_BUSOFF_ERROR can status flag that is propagated either via callback or event like the other status flags.

It also offers a function to resume the bus online, that can be called by the application when CAN_BUSOFF_ERROR is catch.

I also have another FDCan patch to make filtering a little bit faster : in the current implementation of filters, all the filters are enabled, and the filters not in use just filter nothing, but filtering hardware have to try them all. I have a patch that dynamically adjust the filter table length, I choose not to submit it because it add some code complexity, to gain only 100ns of lag between last bit of frame, and message delivery, so perhaps it's not really useful, but I can post it on demand.

Alexandre

[ych]

...
I also have another FDCan patch to make filtering a little bit faster : in the current implementation of filters, all the filters are enabled, and the filters not in use just filter nothing, but filtering hardware have to try them all. I have a patch that dynamically adjust the filter table length, I choose not to submit it because it add some code complexity, to gain only 100ns of lag between last bit of frame, and message delivery, so perhaps it's not really useful, but I can post it on demand.
...

Alexandre, you mentioned a reduction of 100ns in lag due to your patch. Is this a measured value or an estimated one?

[alex31]

I made measures with a Logic Analyzer, and I measured a little bit less that 100 ns in the worse situation, on fdcanV2 witch 32 entries in the extended id filtering table.

In fact, what I cannot measure, is when you have few filters, and none of them successfully trigger, so the peripheral has to examine all the table. I don't know if this will slow down the filtering of the next message in case of heavily loaded bus at high baudrate.

A.

[Edoardo1982]

Hello,

I have backported trunk fdcan to stable, and so far, it works both for fdcanV2 (using watermark) and fdcanV1 (using new message IT)

1) I want to submit trivial patch to add TDCR (transmit delay register) to configuration structure : when using FDCAN at high baudate, it make transmission way more reliable.

To enable TDC, one has to :
1/ setting FDCAN_CONFIG_DBTP_TDC bit in DBTP register
2/ setting TDCR register (there is advice in reference manual to calculate the two fields TDCO and TDCF)

2) when not all the nodes on the bus are powered at the same time, first node try to send and nobody answer, no this first node retransmit frame for a while until it gives up, going offline. There is way to detect this situation : if canTransmitTimeout return with a timout condition, and FDCAN_CCCR_INIT is set in the CCCR register.
restoring the node online is done when resetting FDCAN_CCCR_INIT bit in CCCR register.

would be nice to have an abstracted way to test if node is offline, and to set it online again.

3) is it possible to backport hdcan driver in stable ?

Thanks
Alexandre

Hi Alex,
As for adding a field to the configuration, there are no issues. However, I have some concerns about error handling.
Rather than introducing low-level APIs, I would suggest calling a stop and start of the driver instead. Do you have any objections to this potential solution?

Code: Select all

  struct can_instance *cip = p;
  event_listener_t el;
  chEvtRegister(&cip->canp->error_event, &el, 0);

  while (true) {
    if (chEvtWaitAnyTimeout(ALL_EVENTS, TIME_MS2I(100)) == 0)
      continue;
    eventflags_t flags = chEvtGetAndClearFlags(&el);

    if (flags & CAN_BUS_OFF_ERROR) {
      /* Reset peripheral.*/
      canStop(cip->canp);
      chThdSleepMilliseconds(10);

      canStart(cip->canp, &cancfg);
      chThdSleepMilliseconds(10);
    }
  }
  chEvtUnregister(&cip->canp->error_event, &el);



[alex31]

Hi,

Rather than introducing low-level APIs, I would suggest calling a stop and start of the driver instead. Do you have any objections to this potential solution?

I understand the inconvenience to add new low level API.

In a typical application there is a reception thread, emissions are spread across the code possibly in different threads, and there is a thread that manage error events, like the one in your post.

I am OK with your solution if it does not make failing assert in the Driver if there is blocking transmit or receive in another threads when the stop start is done. If it just make the receive / transmit function to exit gracefully with MSG_RESET status, it is better than adding new API.

The low level API that just set INIT bit is transparent to transmitting or receiving threads behavior.

Alexandre

[Edoardo1982]

Hi,

Rather than introducing low-level APIs, I would suggest calling a stop and start of the driver instead. Do you have any objections to this potential solution?

I understand the inconvenience to add new low level API.

In a typical application there is a reception thread, emissions are spread across the code possibly in different threads, and there is a thread that manage error events, like the one in your post.

I am OK with your solution if it does not make failing assert in the Driver if there is blocking transmit or receive in another threads when the stop start is done. If it just make the receive / transmit function to exit gracefully with MSG_RESET status, it is better than adding new API.

The low level API that just set INIT bit is transparent to transmitting or receiving threads behavior.

Alexandre

Hi Alex,

I have committed the modification to the FDCAN driver on the trunk, adding the new field to the configuration structure. I did not include the low-level functions (refer to the note in the reference manual RM0433 Rev8, section 56.5.13).

I’m attaching an example that handles the BUS_OFF event using start and stop along with mutexes. Could you test it and provide me with feedback?

Edoardo

[alex31]

Hello,

I have backported your proposed FDCAN driver from trunk to stable 21.11, and use it in my projects (H753 and G491), and so far all is working

I agree that with mutex one can stop and start the driver, I have tested this solution and it works, with the burden of having to protect all the CAN driver access with mutex.

Thanks for the integration, when it will be backported to stable, our projects will work on vanilla ChibiOS and that is fine !

Alexandre