2025-05-29 1:55 PM - last edited on 2025-05-29 1:59 PM by mƎALLEm
Board & Setup:
STM32H563RGT6 running FDCAN2 in Normal mode (HAL_FDCAN_Init, Mode=FDCAN_MODE_NORMAL)
SN65HVD230 transceiver in silent mode (Rs pin connected to 3.3V) (120 Ω intergrated) wired with a single 120 Ω terminator at the far end
No other pull-up/down or termination changes when the USB–CAN dongle is unplugged
Filters configured (Reading the data from the BMS of a custom battery):
FIFO0 → IDs 0x1E0 (BMS_STATE), 0x1E2 (PACK_MINMAX), 0x1E3 (PACK_AVG)
FIFO1 → ID 0x1E1 (PACK_VALUES)
Symptom:
With the USB–CAN adapter or another node on the bus, everything works: the real BMS sends all four messages, our STM32 ACKs them, and they appear in Cangaroo.
As soon as the USB–CAN dongle is unplugged (or if our transceiver is switched to any other mode -> Slope control or High speed (no slope control)), no messages are observed on the bus—even though the BMS should still be broadcasting at 1 Hz (it constantly spits out data at a 1 Hz rate) and our STM32 is in Normal mode.
What I need:
Keep the SN65HVD230 in Normal (ACK-capable) mode—tie its RS pin LOW (or drive it low in GPIO init).
Still “ignore” any frames I transmit (because I’m not sending any), so that I only see the BMS frames.
How do I ensure my SN65HVD230 is always in normal, ACK-capable mode (so the BMS sees at least one ACK and keeps talking), while my STM32 itself continues to filter out any of its own (non-existent) messages so I only capture IDs 0x1E0–0x1E3?
***My STM32CubeIDE "main.c" is given in attachments.
2025-05-29 1:58 PM - edited 2025-05-29 2:03 PM
Hello @aqua_dev and welcome to the ST community,
Not sure I understood your configuration.
Just to be clear, if you are in Normal mode you need at least a second node on the bus to make acknowledgement mechanism works properly, otherwise you need to use Loopback mode instead.
There is no intelligence at the transceiver level, so the Acknoledgement is managed at CAN interface level in the MCU.
2025-05-29 2:03 PM
The battery (or BMS) I was talking about is a node which is connected to the CAN bus. The "master" is the SN65HVD230 transceiver which is connected to the CAN Tx and Rx of the STM32H563RGT6 (pins PB5 and PB13 to be exact -> FDCAN2).
2025-05-29 4:52 PM - edited 2025-05-29 4:54 PM
SN65HVD230 transceiver in silent mode (Rs pin connected to 3.3V) (120 Ω intergrated) wired with a single 120 Ω terminator at the far end
So, RS pin is connected to 3.3V directly or has a pull-up resistor to 3.3V?
Does the USB–CAN adapter have a terminating resistor enabled?
If so, it sounds like the STM32 terminating resistor may be an open circuit? So when you remove the USB–CAN adapter, there is only 1 terminating resistor on the far end. The USB–CAN adapter is probably the node that is sending the ACK, not the STM32.
Draw a block diagram showing your nodes, CAN bus wires, and where the terminating resistors are.
2025-05-30 6:40 AM
Now many nodes are on the bus?
If it is just the BMS and the STM (when the CAN-USB is disconnected) and the STM is not able to transmit on the bus, then there is nothing to send the 'ack' bit when the BMS sends it's message and it will go error passive. A receive-only node like the STM will only receive messages that are acknowledged by another node that is capable of transmitting messages.
2025-05-30 7:19 AM
I have a switch that connects the Rs pin directly to 3.3V or to a 10k resistor to ground. Right now the only way it works is directly connected to 3.3V.
The USB-CAN terminating resistor is enabled, but I tried to disable it and it didn't seem to be the problem. This totally makes sense, it's the conclusion I'm leaning towards -> The USB–CAN adapter is probably the node that is sending the ACK, not the STM32.
2025-05-30 7:30 AM
There is no integrated 120 ohm resistor on the SN65HVD230 neither to any CAN transceiver in the market.
But is is available in your hardware outside here:
Try to shunt the R1 resistor so Rs pin will be connected directly to the ground:
2025-05-30 7:47 AM
Shunting the R1 resistor didn't seem to affect the problem.
2025-05-30 7:59 AM - edited 2025-05-30 8:00 AM
Not clear how many 120 ohm terminating resistors in your CAN bus:
What I suggest is to power off all the nodes and measure the resistance between CAN_H and CAN_L.
You need to have ~60ohm resistor value equivalent to 2x120 ohm resistors in parallel.
2025-05-30 8:03 AM
So from the Hardware point this seems OK.
Are You sure that the STM32 is configured at the right baud-rate?
I don't know the SH-C30A converter, but many of the low cost converter will not give you any warning if the bus has error frames or is otherwise blocked by a Node that has a wrong configuration.
My gess is that the STM32 is blocking the bus because he is not configured as he should be.