2020-02-19 10:44 AM
Hello,
I have the stm32mp157c-dk2 board and have connected two CAN Bus transceivers to it.
FDCAN1 is assigned to the A7 CPU and the FDCAN2 is assigned to the M4 CPU.
Both transmitters are connected to the same CAN bus. There is also a 3rd device connected to the same can bus.
When there is very low traffic on the can bus everything is fine.
All messages from all 3 CAN nodes can be received correctly everywhere.
When there gets little more traffic on the bus then the FDCAN2 on the M4 CPU starts to transmit wrong frames.
Also when the traffic goes low again the problem stays the same until reboot of the M4 CPU.
It is also hard to reproduce the issue. It sometimes takes a few hours or days for the issue to happen.
Here is the data on the bus when everything is ok:
# candump can0
can0 10000681 [3] 0A 00 05 <- Data from M4 CPU
can0 10000682 [3] 0A 00 19 <- Data from M4 CPU
can0 1810A080 [8] 80 00 00 18 00 01 00 00 <- Data from 3rd device
can0 18E050E5 [8] 00 00 00 00 08 00 00 00 <- Data from 3rd device
can0 02200000 [8] 10 04 00 00 00 00 00 00 <- Data from A7 CPU
can0 02200000 [8] 12 00 00 00 00 00 00 00 <- Data from A7 CPU
Here is the data on the bus when the M4 CPU gets a problem (all devices are still sending exactly the same frames):
# candump can0
can0 1F080681 [3] remote request <- Data from M4 CPU
can0 1F080682 [3] remote request <- Data from M4 CPU
can0 1810A080 [8] 80 00 00 18 00 01 00 00 <- Data from 3rd device
can0 18E050E5 [8] 00 00 00 00 08 00 00 00 <- Data from 3rd device
can0 02200000 [8] 10 04 00 00 00 00 00 00 <- Data from A7 CPU
can0 02200000 [8] 12 00 00 00 00 00 00 00 <- Data from A7 CPU
So the CAN ID 0x10000681 is getting to 0x1F080681 and also the payload is lost.
It looks like something goes wrong in the M4 can bus memory.
Any ideas?
2020-02-19 11:34 AM
There is one possibility, the clock not accuracy enough.
Do you use HSI for the clock source?
2020-02-19 12:22 PM
I am using the HSE clock for FDCAN. Also FDCAN1 and FDCAN2 are sharing the same clock source - it's not possible to use different sources for them. So at least FDCAN1 and FDCAN2 must always be in clock sync. If there would be any clock issues I would get a problem with the communication to the 3rd device and not between the A7 and M4 CPU.
2020-02-19 02:19 PM
Same clock source doesn't means "FDCAN1 and FDCAN2 must always be in clock sync", A7 and M4 running different frequency and instruction different.
You can't assume this.
For my experience, debug time you can not assume anything before confirm, otherwise you will missed something important.
Another difference between FDCAN1 and FDCAN2 is, only FDCAN1 support TTCAN.
I am not sure your board is prototype or mass production, if it worth, you may try got another stm32mp157c-dk2 board, two stm32mp157c-dk2 board only use FDCAN1and same CPU/MPU, this may reduce timing difference between two FDCANs.
2020-02-21 01:50 AM
Maybe check that the address assignment of FDCAN1 and FDCAN2 in the shared 10KB message RAM does not overlap.
From RefMan : The FDCAN does not check for erroneous configuration of the message RAM. Especially the configuration of the start addresses of the different sections and the number of elements of each section has to be done carefully to avoid falsification or loss of data.
2020-02-21 02:47 AM
Yes, I think that this was actually the problem. The uboot DTS was initializing the FDCAN1 and FDCAN2 differently than the kernel DTS.
After setting same addresses in both DTS files it seems to work now. I could no see any issues since 24 hours.
UBOOT init:
m_can1: can@4400e000 {
compatible = "bosch,m_can";
reg = <0x4400e000 0x400>, <0x44011000 0x1400>;
reg-names = "m_can", "message_ram";
interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "int0", "int1";
clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
clock-names = "hclk", "cclk";
bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
status = "disabled";
};
m_can2: can@4400f000 {
compatible = "bosch,m_can";
reg = <0x4400f000 0x400>, <0x44011000 0x2800>;
reg-names = "m_can", "message_ram";
interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "int0", "int1";
clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
clock-names = "hclk", "cclk";
bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
status = "disabled";
};
Kernel init:
m_can1: can@4400e000 {
compatible = "bosch,m_can";
reg = <0x4400e000 0x400>, <0x44011000 0x1400>;
reg-names = "m_can", "message_ram";
interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "int0", "int1";
clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
clock-names = "hclk", "cclk";
bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
status = "disabled";
};
m_can2: can@4400f000 {
compatible = "bosch,m_can";
reg = <0x4400f000 0x400>, <0x44011000 0x2800>;
reg-names = "m_can", "message_ram";
interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "int0", "int1";
clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
clock-names = "hclk", "cclk";
bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
status = "disabled";
};
2020-02-21 03:08 AM
Thanks a lot for your investigations
2020-02-21 03:35 PM
Hi Artem,
It looks like you are way ahead of me, I've just got stm32mp157c-dk2 board and trying to start using it in CAN applicartion. How did you wire the FDCAN2 TX and RX pins on this board? Looking at the board schematics (MB1272-DK2-C01_Schematic.pdf file), I can only find PA11(FDCAN1_RX) and PD1(FDCAN1_TX) traced to bard connectors, but it looks like default FDCAN2 pins (PB5/PB13) are not exposed on this board? Are you using the alternate functions of some other pins to map these signals to board connectors? Can you share details?
-albertr
2020-02-22 12:54 AM
I am using this pins:
FDCAN1: PA11 (RX) PA12 (TX)
FDCAN2: PB12 (RX) PB13 (TX)
2020-02-24 04:51 AM
Thanks, Artem! How did you make the device tree files for this pin mapping? With CubeMX?
-albertr