STM32H743I-EVAL FDCAN can not receive

[Aaron Chang]

Posted on August 17, 2017 at 13:48

Hello,

    I tried the example 'FDCAN_Com_polling' on STM32H743I-EVAL, it worked like it should be.

Then I separated the example code into TX part and RX part, made one of my 

STM32H743I-EVAL board as TX and another as RX, but the RX did not work, it never received anything and the HAL_FDCAN_GetRxFifoFillLevel always get 0.

All jumpers and SBs on the EVAL board were removed or connected following the instructions on the EVAL's reference manual, and I checked the waveform on the RX side and it seems correct.

The filter setting should be good as well because the TX side can receive its own loop back frame by using the same filter settings.

Any hint what went wrong or which part should check next? 

Thanks in advance.

#fdcan #stm32h7

[Amel NASRI]

Posted on August 17, 2017 at 15:57

Hi

aaron_chang

‌,

Is the same example tested successfully with the 2nd eval-board?

Do you have always same issue on RX side if you switch the used boards?

-Amel

[Amel NASRI]

Posted on August 17, 2017 at 17:10

Hi again

aaron_chang

‌,

Please note that you can get further dedicated support from your local FAE to more understand what is going wrong.

-Amel

[Aaron Chang]

Posted on August 17, 2017 at 16:21

Hi Amel,

  Each board runs the example can send out frames correctly (I can see the waveform on scope) and receive the loop back frame.

But neither of them can receive frames from the other.

I'm assuming the loop back frame was passed through an internal path rather than through the PCB, because I ever removed a jumper to isolated

the TX port, and it still received the loop back frame.

 -Aaron

[Aaron Chang · Accepted solution]

Posted on August 18, 2017 at 04:03

It turns out that the FDCAN_CCCR_TEST bit was set and never been cleared.

It seems that once the FDCAN is initialized into LoopBack mode, the 

FDCAN_CCCR_TEST bit is set and no HAL api can clear it.  Not even after the FDCAN was DeInit and re-Init again.  I think it is a bug in the HAL and hope it will be fixed.

[Amel NASRI]

Hello,

Please note that this issue is fixed in the latest STM32CubeH7 package (Version 1.4.0, available on the web since last week).

-Amel