CAN Frame Repeating, but is received

[sethkaz]

Summary: I'm seeing a situation where the CAN frames are repeating when they should only be sent once.  However, the receiving device is receiving them just fine.  

Details:

I'm running an STM32U545 on it's Nucleo Board, and using a simple CAN transceiver chip.  I'm sending pre-made dummy messages to spoof an external device, and have verified those messages work using an STM32L431.  The frame is being sent once every 200ms, and the code is sitting in HAL_Delay() the rest of the time.  

The number of repeated frames is not consistent.  I'm looking on the scope/Saleae, and it can be anywhere from 1 to several (like 7 or 10), and anywhere in between.  The Saleae interpreter is reporting an ACK being received, so that shouldn't be the issue.  

Bit rate: 250k

Is there anything else I should check?

[SofLit]

Hello,

If you disable the auto-retransmission? do you get the same behavior?

[sethkaz]

Auto-retransmission was already disabled.  I tried enabling it, but it didn't fix the problem.  Nor did re-disabling it.  

I also tried changing it from FIFO to Queue mode, and no change in behavior. 

[SofLit]

You need to share your code for the two nodes STM32U545 and STM32L431.

What tranceiver you're using for both nodes?

What clock source are you using for both nodes? HSI? HSE? 

[sethkaz]

I should be able to share my code, but let me double check before I do.

I'm using the VP230 transceiver for both.  

Clock source:
U545: PLL1Q @ 40MHz,  sourced by MSIS running at 4MHz
L431: MSI @ 48MHz. (I'm not seeing a dedicated CAN clock mux in the clock config window, so I'll have to hunt down which specific clock it's running off of, but they're all set to 48M)

[SofLit]

It's not recommended to use internal oscillators for CAN communication. You need to use an external crystal (HSE)

[sethkaz]

Unfortunately, the Nucleo Board I have is missing the HSE oscillator.  I've ordered it from Digi-Key.

Is that recommendation documented in the datasheets somewhere?  (For my own knowledge, and ideally with an explanation why)

Also, is there something else we can eliminate while we wait for the oscillator to arrive?

And why is that working for the L431 chip, while it's failing for the U545 chip?

[sethkaz]

I've attached the pertinent code for the U545 and L431 projects.  Everything not included is left as is from how the project is generated by STM32CubeIDE 1.13.

[Karl Yamashita]

Ordering the oscillator was unnecessary. The oscillator is left out because your clock source is derived from the ST-Link MCO output.

A simple Google search for the Nucleo boards will have links to ST's website for that board. From there they have all the documents including the schematics. From the schematics you would have known the oscillator is DNF. You then would have seen in place of the oscillator, the MCO goes to the oscillator input.

If you used STM32CubeIDE to set up the board, then the clock has already been set up correctly.

[Karl Yamashita]

---

@sethkaz wrote:

I've attached the pertinent code for the U545 and L431 projects.  Everything not included is left as is from how the project is generated by STM32CubeIDE 1.13.

---

Your FDCAN_TxHeaderTypeDef txHeader_status needs to be defined as global instead of local. As soon as you exit the function, txHeader_status is destroyed.