2022-08-11 07:23 AM
I've been working on the STM32H730 processor and have been struggling to get the FDCAN peripherals to switch between classical CAN and CAN FD for transmissions. It seems that when I'm transmitting as classical CAN everything works fine. Then when I stop the peripheral using HAL_FDCAN_STOP, reconfigure it to operate as CAN FD using HAL_FDCAN_Init, start the peripheral back up using HAL_FDCAN_START, and then perform a transmission I see the TX fail multiple times (AutoRetransmission is on) before finally succeeding. It always fails at least once, but sometimes see it fail 5+ times.
I definitely could be doing something wrong, but I'm curious if anyone has done this successfully or if it's just not something that can be handled gracefully as its expected you choose one at startup and not switch, and this is just what you see if you try switching. Providing a snippet of a logic analyzer capture to show it "failing". First one is a successful classical TX, the rest are CAN FD attempts before succeeding. As a side note, if I use my CAN FD configuration at startup and don't switch CAN FD works as expected on the first TX.
EDIT: One note after looking into this more. I've come to the realization that I do not need to reconfigure between classical and CAN FD. I can simply configure the peripheral as CAN FD and then just mark the message in the TX header as classical or CAN FD and it'll correctly send it as one or the other. However I am still seeing this same issue going that route. I'm starting to think it has to do with my CAN FD configuration. I'm trying to do CAN FD with BRS, with baud rates of 500 kbps and 2 Mbps.
Solved! Go to Solution.
2022-08-19 08:58 AM
Want to give an update if anyone else runs into this. Turns out its not the processor or the code that is the problem. What I was seeing was because I had a classical CAN device on the bus and it was erroring the FD attempts of our device. I found out classical CAN nodes can not operate on FD busses because of this fundamental issue. Once I turned off my classical CAN node, all transmissions worked perfectly fine and I saw no issues. So the answer is yes you can transmit both classical and CAN FD messages just fine on a bus; however there is probably no point because only other CAN FD devices can be on the bus anyway so you might as well just use CAN FD messages. In order to put classical CAN devices onto an FD bus you have to workaround this issue by either putting a special CAN transceiver on the device that doesn't do this, or create custom software on the device where the CAN FD device can tell it to ignore the FD TX that is about to happen. So yeah, you might as well just keep an isolated bus for the CAN FD devices, as the workarounds are probably more costly anyway.
2022-08-11 09:19 AM
One note after looking into this more. I've come to the realization that I do not need to reconfigure between classical and CAN FD. I can simply configure the peripheral as CAN FD and then just mark the message in the TX header as classical or CAN FD and it'll correctly send it as one or the other. However I am still seeing this same issue going that route. I'm starting to think it has to do with my CAN FD configuration. I'm trying to do CAN FD with BRS, with baud rates of 500 kbps and 2 Mbps.
2022-08-19 08:58 AM
Want to give an update if anyone else runs into this. Turns out its not the processor or the code that is the problem. What I was seeing was because I had a classical CAN device on the bus and it was erroring the FD attempts of our device. I found out classical CAN nodes can not operate on FD busses because of this fundamental issue. Once I turned off my classical CAN node, all transmissions worked perfectly fine and I saw no issues. So the answer is yes you can transmit both classical and CAN FD messages just fine on a bus; however there is probably no point because only other CAN FD devices can be on the bus anyway so you might as well just use CAN FD messages. In order to put classical CAN devices onto an FD bus you have to workaround this issue by either putting a special CAN transceiver on the device that doesn't do this, or create custom software on the device where the CAN FD device can tell it to ignore the FD TX that is about to happen. So yeah, you might as well just keep an isolated bus for the CAN FD devices, as the workarounds are probably more costly anyway.