cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 FDCAN: Frames visible on CANable (candump) but TX still reports ACK error — scope shows ACK notch

suyog1
Associate II

TL;DR:

  • Two-node bus: STM32 (FDCAN1)CANable (SocketCAN) at 500 kbit/s

  • candump can0 shows frames from STM32, but STM32 keeps flagging ACK error and increments TxErrorCnt.

  • Scope on CANH/CANL (diff trace CH1–CH2) shows a dominant ACK bit in the ACK slot (!)

  • External loopback works.

  • Looks like my MCU isn’t “seeing” the ACK at its RX input—looking for eyes on transceiver mode pins, RX pin mapping/AF, and timing.

Hardware

  • MCU: STSpin32G4 

  • Transceiver: SN65HVD230DR

  • Other node: CANable / candleLight  on Linux as can0.

  • Wiring: STM32 TXD/RXD ↔ CAN transceiver ↔ twisted pair to CANable.

  • Termination: 120 Ω at each end (I can measure ~60 Ω between CANH–CANL with power off; will re-check if requested).

  • Ground: Common GND between boards.

If helpful, I have shared the schematic snippet for the transceiver pins .

What works vs. what fails

Works

  • External loopback mode: frames “succeed.”

  • candump sees frames from STM32 in normal mode.

  • Scope on CANH/CANL shows clean dominant bits. The CH1–CH2 differential (pink) clearly shows a dominant pulse in the ACK slot.

Fails

  • In normal mode, FDCAN reports ACK error on every frame; TxErrorCnt climbs (I previously hit Error Warning/Passive).

 Any insights or “you missed this obvious thing” would be hugely appreciated. Thanks!

 

20250924_132429.bmp

 

20250924_133627.bmp

suyog1_0-1758703163149.png

Screenshot from 2025-09-24 11-49-28.png

1 ACCEPTED SOLUTION

Accepted Solutions
suyog1
Associate II
 

There was an manufacturing defect in my board. The D and R pins were shorted while the MCU was soldered IG... Anyways, I checked with the other board which did not have an short and it worked very well.

@all Thankyou for your help.

View solution in original post

5 REPLIES 5
Ozone
Principal II

I don't see anything obvious.
I don't have much experience with the STM32 CAN interface, although my company uses all sorts of CAN devices.

Perhaps you can try a lower baudrate, and play with the bit timing parameters (what the CAN spec calls "quanta").
The latter e.g. define at what point during a signal the IP samples the ACK.

 

suyog1
Associate II

   

Channel 1 - CAN H

Channel 2 - CAN L

Channel 3 - D

Channel 4 - R

 

 

20250924_174942.bmp

20250924_174958.bmp

20250924_175032.bmp

MHoll.2
Senior III

Possibile problems in You configuration:

1) The 47k Resistor on the RS pin will reduce the slew rate, this could be to slow for 500 kBit/s.

2) You are setting the sample point at about 94%, normaly the sample point is set to 87,5% (CanOpen).

Try the Can bit timing calculator from Kvaser (https://kvaser.com/support/calculators/can-fd-bit-timing-calculator/)

Hello,

As said by @MHoll.2 , your sample point is set at a too late position on the bit time. CanOpen recommands ~87,5%.

Try these timing parameters set at 87,87%:

mALLEm_0-1759061110722.png

I do agree also on the fact that 47k is a bit high value, try to ground Rs pin.

 

 

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.
suyog1
Associate II
 

There was an manufacturing defect in my board. The D and R pins were shorted while the MCU was soldered IG... Anyways, I checked with the other board which did not have an short and it worked very well.

@all Thankyou for your help.