I'm working with the STM32L552ZEQ, and I'm noticing that it is sending duplicate CAN transmissions.

I have two threads, one that adds transmissions to a FreeRTOS queue, and one that spins and transmits enqueued messages.

The thread that enqueues a message, calls osDelay(1000), enqueues the exact same message again, and then calls osDelay(1000).

The other thread just spins and waits for a message to be enqueued. It dequeues it and then transmits.

The problem I'm having is that for some reason, the second message that is enqueued is transmitted 4 times instead of just 1. It's the exact same function and arguments as the first.

When I enqueue a different message each time, I was able to confirm that it wasn't just an issue of the second message getting enqueued 4 times. In other words, thread 1 enqueues message 1, sleeps, and then enqueues message 2 (repeating the process). Thread 2 gets message 1, transmits, sleeps, and then gets message 2, transmits, and then sleeps. Using the oscilloscope, I confirmed that the peripheral is literally transmitting 4 times.

I've also confirmed that in each case, HAL_OK is returned (and everything looks good when I step through the HAL code).

This will also happen even if auto retransmit is turned off.

Any idea what is going on?

TLDR: I have various modules that all need to use the CAN Bus. Rather than letting each one have access to the hardware, they all add messages to a queue, and then the transmit thread sends each over the bus. There's something going on timing wise that's causing the FDCAN peripheral to transmit the same message 4 times instead of just once. The same message printed twice in two seconds seems to do this.

  • 1
    \$\begingroup\$ Is anything else connected to the bus? The STM32 CAN controller will resend the message unless another node sets the ACK field of the frame. \$\endgroup\$
    – Jon
    Apr 21, 2022 at 20:36
  • \$\begingroup\$ The STM32 node with its transceiver and PCAN-USB are on the bus. Both are timed at 1 Mbps. \$\endgroup\$
    – Dan
    Apr 21, 2022 at 20:40
  • \$\begingroup\$ Do you osDelay after the data has completed shifting out? Because it can be you call osDelay while CAN is physically hasn't finished sending the stuff, so it could mess something up? \$\endgroup\$
    – Ilya
    Apr 21, 2022 at 21:20
  • \$\begingroup\$ I dont think so. The transmit thread is delaying for 20 ticks. The enqueueing thread is delaying for 1000 ticks. The other thing is that STM32's FDCAN has an FIFO built into the peripheral, and so it should simply be added to the peripherals fifo (if the fifo is full, then it returns error). The only way I could see that causing the issue is if there's a hardware bug in the STM32. \$\endgroup\$
    – Dan
    Apr 21, 2022 at 22:37

1 Answer 1


Somehow, changing the frequency from 20 MHz to 8 MHz stopped the duplicate transmission issue. I don't know why this worked. If you get a weird packet duplication issue, try changing the clock frequency or the clock source.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.