cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 FDCAN node sees nothing on bus when CAN-to-USB adapter removed

aqua_dev
Visitor

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:

  1. Keep the SN65HVD230 in Normal (ACK-capable) mode—tie its RS pin LOW (or drive it low in GPIO init).

  2. 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.

24 REPLIES 24
mƎALLEm
ST Employee

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.

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.

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

Karl Yamashita
Principal

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.

 

Don't worry, I won't byte.
TimerCallback tutorial! | UART and DMA Idle tutorial!

If you find my solution useful, please click the Accept as Solution so others see the solution.
CTapp.1
Senior II

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.

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.

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:

mALLEm_0-1748615327849.png

Try to shunt the R1 resistor so Rs pin will be connected directly to the ground:

mALLEm_1-1748615402470.png

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.

Shunting the R1 resistor didn't seem to affect the problem.

Not clear how many 120 ohm terminating resistors in your CAN bus:

mALLEm_1-1748617064021.png

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.

 

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.

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.