• State TI Thinks Resolved
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 63 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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

suyog chougule
Prodigy 20 points
Part Number: SN65HVD230

Tool/software:

TL;DR:

  • Two-node bus: STM32 (FDCAN1) Left right arrow 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 Left right arrow CAN transceiver Left right arrow 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!

 


 

 

 

  • 0
    TI__Guru 51666 points

    Hi Suyog,

    It would seem the RXD pin 4 of the transceiver is not mapped correctly to the STM32 I.e. wrong AF / wrong pin or silent mode accidentally set in FDCAN, where it may not ACK (see if any init flags)

    • Do you see R output toggle at all, within proper VOH / VOL levels? Notice the schematic shows this as an input (should be an output).
      • Issue is most likely with the wiring / wrong transceiver state if RX do not show the ACK while the bus differential does
      • Issue is most likely with the FDCAN (timing / sample / config) if RX shows the dominant ACK. Double check the controller's config - use standard settings / sampling points, ensure controller is not in a silent mode, ensure normal mode for ACK checking, ensure FD mode is disabled if only classical CAN at 500 kbps needed, etc.
    • Also, verify the bus impedance is 60 ohms, thanks.

    Best Regards,

    Michael.

  • 0 in reply to Michael Ikwuyum
    Prodigy 20 points

    Hello Michael,

    Do you see R output toggle at all, within proper VOH / VOL levels?
    -> Yes
    I have attached the output for reference. Please let me know it something seems wrong here.

    Channel 1 - CAN H

    Channel 2 - CAN L

    Channel 3 - D

    Channel 4 - R




    It would seem the RXD pin 4 of the transceiver is not mapped correctly to the STM32

    -> I checked it, its correct

    verify the bus impedance is 60 ohms

    -> yes, its ~60 Ohms


  • 0 in reply to suyog chougule
    TI__Guru 51666 points

    Hi Suyog,

    Thanks for confirming.

    Could you also confirm issue do not correlate to the MCU pin config / FDCAN peripheral settings? Bypass the transceiver and see if it works by connecting the CANable directly to MCU RX temporarily to confirm if the peripheral sees the external RX dominant. If issue persists, this can imply a controller issue and would recommend reaching out to the appropriate manufacturer / experts while taking a closer look at the below few, thanks.

    • With transceiver toggling, confirm the peripheral connected sees it by ensuring AF assigned is for the same FDCAN instance initialized.
    • Verify you can read the RX sample directly from the peripheral during the TX + ACK.
      • If no dominant samples, confirm timing / sample points / instance mismatches.
    • Verify GPIO register if the GPIO is actually AF input and not GPIO output.
    • Verify MCU is not driving the RX pin / any chance of a push pull output fighting the transceiver producing your symptoms.
    • You may also temporarily disable filters to allow any ID i.e., verify the peripheral is not ignoring frames.

    Best Regards,

    Michael.