0
\$\begingroup\$

I am using an STM32 to transmit data over CAN using CAN2. Currently, my code is only setting up the can peripheral and sending periodic messages. My messages usually look like this on the receiving side: can0 002 [1] 00, as recorded by candump.

Unfortunately, sometimes the stm32 spits out this: can0 002 [2] 00 D0. I am definetly not sending D0, yet it keeps coming back. 01 becomes 01 C6 and03 C6 sometimes. 02 becomes 02 C6 and 05 EA. The patterns in a failure are predictable.

Increasing the bitrate seems to reduce the chances of failure, but they still occur.

It is like the CAN peripheral is being interrupted mid-transmission, but is that even possible?

I measured the garbage data on the STM can_tx pin, so the transceiver/wiring should not be to blame.

Is there any possibility of interference with my CAN2 peripheral? Is there a setting I am missing?

\$\endgroup\$
4
  • \$\begingroup\$ Very hard to answer without seeing your code, setup etc. \$\endgroup\$
    – KarlKarlsom
    Commented Dec 22, 2023 at 5:39
  • \$\begingroup\$ I understand, I am using an MCP2515. I was hoping for someone to just pop up and say "hey, I had exactly the same problem". Unfortunately, my code is too messy to share right now... \$\endgroup\$
    – Daniel D.
    Commented Dec 22, 2023 at 5:50
  • \$\begingroup\$ Don't use MCP2515. Get a real microcontroller with controller built-in, suitable for your project. \$\endgroup\$
    – Lundin
    Commented Dec 22, 2023 at 7:48
  • \$\begingroup\$ Well, the sending side is an stm32 with can build in. That is what is causing the issues... \$\endgroup\$
    – Daniel D.
    Commented Dec 22, 2023 at 16:05

1 Answer 1

Reset to default
1
\$\begingroup\$

The bus was working between two MCP2515, but not with an STM32 involved. The issue turned out to be a disabled HSE (external crystal) on the STM32. CAN apparently only reliably works with an external crystal.

\$\endgroup\$
1

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