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

[suyog1]

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!

 

 

[Ozone]

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]

Channel 1 - CAN H

Channel 2 - CAN L

Channel 3 - D

Channel 4 - R

 

 

[mƎALLEm]

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%:

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

 

 

[MHoll.2]

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/)

[suyog1]

 

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.