G431pin-multiplexing-in-fdcan1: in Different GPIO Port

[HL_Efeng]

As addicated in DataSheet and CubeMX, there are two FDCAN1_Tx and two FDCAN1_RX in STM32G431CBT6. In my Prj, I used PA12 for Tx and PB8-BOOT0 for Rx, and my chip can only work in FDCAN_MODE_Ext._Loopback, and without any receive func be implemented. After I changed the FDCAN pin from PA12&PB8 to PB9&PB8 and adjusted my wire routing, the problem has be handled. so If the STM32G4 can use FDCAN pin from different port in some case? If not. I think it should be fixed in CubeMX, because CubeMX allows users to select CAN pin from different ports without any warning.​

[HL_Efeng]

nothing is connected to PA12 apart from the CAN tranceiver.

External loopback works good when PA12 and PB8 are used.

that is my doubting point. In the chip, PA12 is beside PA11(another FDCAN1_RX pin like PB8), and PB9 is beside PB8.

I think maybe it can only run in PA11&12 or in PB8&9 ，but cannot run in one PA & one PB. It matches my intuition: a PHY inside the chip maybe responsible for some protocol work independent from CPU, and PA11&12 and PB8&9 may using two PHY which is non-interoperable, so the PHY in PB can not determine what the bit sent by PA12, or the PHY in PA can not receive the bit that PB8 sent. In this case, neither PHY inferrs CPU that a bit is transmitted successfully.

[mƎALLEm]

---

@HL_Efeng wrote:

I think maybe it can only run in PA11&12 or in PB8&9 ，but cannot run in one PA & one PB. It matches my intuition

---

No. you can use any of the CAN pin combinations: PAx/PBx.

Meanwhile, I didn't understand what do you mean by PHY in the CAN context?!!

Only the CAN controller is integrated in the chip. The transceiver needs to be added outside.

I definitely suspect a hardware issue. Either PA12 is broken or you are using another GPIO but you think you are using PA12.

At this stage, I suggest to forget about the CAN communication for now and try to toggle PA12 and check with the scope if PA12 is toggling as expected.

[HL_Efeng]

Sorry for my late reply.
I mentioned "PHY", I meant controller in chip， not the tranceiver. btw, I used TJA1044 as my tranceiver.
I toggled PA12, and I check in the CAN_Tx pin of tranceiver(it was connected together in my PCB). It toggled as expected, and tranceiver will send a bit to bus.
In fact, in Ext.LoopbackMode, it can send msg correctly. this has already inferred that the PA12 is correctly connected.

[mƎALLEm]

 In fact, in Ext.LoopbackMode, it can send msg correctly. this has already inferred that the PA12 is correctly connected.

---

As PA12 is toggling as expected and the loopback mode works correctly but not in normal mode, that's either a hardware issue: broken transceiver, bad wiring or wrong/bad connections.. VIO pin of the transceiver connected to VDD of STM32? You need to inspect all the CAN bus you have.

Or bit timing issue: (but this is not the case since it works with PB9.

So double check again your hardware ... Probe PA12, probe PB9 with a logic analyzer or an oscilloscope and check the differences.

[mƎALLEm]

 In fact, in Ext.LoopbackMode, it can send msg correctly. this has already inferred that the PA12 is correctly connected.

---

As PA12 is toggling as expected and the loopback mode works correctly but not in normal mode, that's either a hardware issue: broken transceiver, bad wiring or wrong/bad connections.. VIO pin of the transceiver connected to VDD of STM32? You need to inspect all the CAN bus you have.

Or bit timing issue: (but this is not the case since it works with PB9.

So double check again your hardware ... Probe PA12, probe PB9 with a logic analyzer or an oscilloscope and check the differences.

[HL_Efeng]

At this point, it seems it can only be attributed to the bad PCB wiring. maybe the signal integrity has bad enough that STM32 cannot read a bit.

Wait. Maybe PB8 has broken? Maybe PA12 has transmitted a bit, but PB8 had not received. Let me check it by GPIO_Input. I will reply here in some days.

Thankyou for your patience.