STM32F303 and L9616 CAN transceiver

enhering · ‎2024-03-24

I have a STM32F303 connected to a L9616 as displayed below.

The pullup resistor R3 is not present any more. Please ignore it.
Vdd is 3.3V but, as can be seen, I have set Vs to 5V, believing that was necessary to make the CAN BUS work.

With an oscilloscope channel connected between CAN_BUS_H and GND I can see a Tx pulse train, but STM32 HAL reports state 2 and error 43 (0x2B) after transmission. If I understood well, this means 0x20 + 0x10 + 0x1 which leads me to believe that the following three errors are occurring:

#define HAL_CAN_ERROR_EWG (0x00000001U) /*!< Protocol Error Warning */
#define HAL_CAN_ERROR_FOR (0x00000010U) /*!< Form error */
#define HAL_CAN_ERROR_ACK (0x00000020U) /*!< Acknowledgment error

Besides that reported error, the most annoying fact is that I tried many ways to fire the Rx Callbacks on another node with similar configurations, without success.

When investigating the problem I measured, on the reception node, CAN_TX at 3.3V and CAN_RX at 5V. I believe this 5V at CAN RX is, somehow, blinding STM32 from the Rx transceiver signal.

Can you help me with some information? Or could you please share a proved working connection diagram between STM32 and L9616 with me?

Best regards,

Hering

enhering · ‎2024-03-25

Thanks again for your kind attention to this topic, @SofLit

This is my system clock configuration:

And these are the CAN settings:

They are different from yours.

Regarding MCP2561, bringing STDBY to GND will require no interventions to the PCB. This is very good news.

Thanks again!

SofLit · ‎2024-03-25

Ok thank you for the sharing and you're welcome 🙂.

I have two questions:

Are you sure, your CAN bus bitrate is 363636b/s?? it's not common bitrate for the CAN protocol. If you're in loopback mode is OK but you have an already established CAN bus. So, could you please check what is your real CAN bus bitrate?
Why you're not using the maximum CPU speed 72MHz?

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

enhering · ‎2024-03-25

I took a picture of the scope:

About the system clock, there is no important reason to be running at low speed. I came from AVR and just did not want to hit hard the accelerator. Increasing to full speed is in the future plans. Should I run it at full clock?

AScha.3 · ‎2024-03-25

>Should I run it at full clock?

You should run it at the speed you need . Not change the core speed here and then, just makes it complicated to adjust all other clocks then and every time again. (to get the setting for UART, USB, CAN, SPI...correct again.)

So setting it at 72M is no problem for the cpu - its the "standard maximum" (as 20M in a AVR ).

Just if for energy saving (view mA only - see ds ) and no need for more speed, run it at low clock speed.

If you feel a post has answered your question, please click "Accept as Solution".

SofLit · ‎2024-03-25

It's better to run at higher system frequencies for optimal function and keep some divider between AHB

I suggest the following system clock config if you don't have any power consumption constraints:

You configured the HSE in bypass mode. Is it intentional? Do you have an external crystal? or Crystal generator? you need to check.

But you didn't answer to my question yet regarding the strange CAN bitrate of 363636b/s. That's important!

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

SofLit · ‎2024-03-25

I would not recommend neither CPU at 8MHz and APB at 8MHz. Need to have some divider between the two for optimum operations. Low clock CAN frequencies decreases the sampling performance of the bit time.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

enhering · ‎2024-03-25

I have an external 16MHz crystal. Maybe that is why the HSE bypass is configured. I sincerely cannot answer your question with certainty.

About the bitrate, how can I measure the real one? I thought the oscilloscope image would give some hint on that. With auto retransmission enabled, the scope shows a CAN frame with a payload of 8 bytes taking about 400us of the bus time. That gives me 2500 frames/s of 8 bytes each, or 160 000 bits/s. But I bet this is not the way the bitrate is measured. But by looking inside the frame, each bit seems to be using around 3 us of bus time, or around 333kbits/s. All these values are approximate as were measured on screen.

I'll move the clock to full speed and see what happens, but that will take some time, as will require some TIM and USART calculation updates to make communication and servos work again.

I can consider myself a happy member of this forum. You guys are great. Thanks again.

enhering · ‎2024-03-25

Probably that will help a lot to improve the communication between the modules.

SofLit · ‎2024-03-25

You need to get your CAN bus bitrate otherwise it couldn’t work. CAN bit time is strict it shouldn’t be calculated approximately, when it’s 500kb/s it should be 500kb/s no more nor less.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

SofLit · ‎2024-03-26

I have an external 16MHz crystal. Maybe that is why the HSE bypass is configured. I sincerely cannot answer your question with certainty.

It depends on the external clock source.

If you are using this kind of crystal (through hole):

You need to configure HSE as following:

If you are using this one (through hole), you can keep it in bypass mode.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.