Skip to main content
Visitor II
February 19, 2020
Question

STM32MP1 FDCAN issues

  • February 19, 2020
  • 12 replies
  • 8053 views

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?

    This topic has been closed for replies.

    12 replies

    Graduate
    February 19, 2020

    There is one possibility, the clock not accuracy enough.

    ​Do you use HSI for the clock source?

    ArtemAuthor
    Visitor II
    February 19, 2020

    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.

    Graduate
    February 19, 2020

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

    Technical Moderator
    February 21, 2020

    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.

    ArtemAuthor
    Visitor II
    February 21, 2020

    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";

                   };

    Technical Moderator
    February 21, 2020

    Thanks a lot for your investigations

    Visitor II
    February 21, 2020

    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

    ArtemAuthor
    Visitor II
    February 22, 2020

    I am using this pins:

    FDCAN1: PA11 (RX) PA12 (TX)

    FDCAN2: PB12 (RX) PB13 (TX)

    Visitor II
    February 24, 2020

    Thanks, Artem! How did you make the device tree files for this pin mapping? With CubeMX?

    -albertr

    ArtemAuthor
    Visitor II
    March 1, 2020

    Yes, I have made the configuration with CubeMX and copied the relevant sections to the kernel dts file.

    Technical Moderator
    February 25, 2020

    Hi Artem,

    I checked both V1.1.0 and V1.2.0 releases and I could not find the dts declaration you mentioned. Was it the devicetree generated by cubemx ?

    I am very suspicious about your correction. If it is working now, that's great but I would like to understand why.

    I/ CAN device is not supported into u-boot:

    • so anyway u-boot declaration about can will have no effect in u-boot
    • stm32mp157c.dtsi file used in u-boot and kernel is the same (u-boot copy/past this file from kernel devicetree)
    • The assumption I have is that your kernel is using u-boot devicetree to boot (some config allow it for ex with grub). Do you think it is realistic ?

    II/ CAN2 device is M4 side on your use case:

    • this means CAN2 is never activated on A7 Side (in u-boot nor in kernel side)
    • this also means CAN2 device is declared in the resource manager (see: stm32mp157c-m4-srm.dtsi for exemple) as a "m4_m_can2" node to reserve the resource for the M4.

    see: https://wiki.st.com/stm32mpu/wiki/How_to_assign_an_internal_peripheral_to_a_runtime_context for more details.

    ArtemAuthor
    Visitor II
    March 1, 2020

    I am using an older u-boot version directly from u-boot - not the stm u-boot. Here you can see that the m_can is initialized differently:

    https://github.com/u-boot/u-boot/blob/5d2901a4b653a5ee47b1a789054414f4e7b8cb85/arch/arm/dts/stm32mp157c.dtsi

    It was also corrected in the commit "ARM: dts: stm32mp1: DT alignment with kernel v5.4" so the upstream u-boot will correctly handle the can bus controller.

    Technical Moderator
    March 2, 2020

    Yes Artem, I can see it. But in ST boot sequence the nodes declared in u-boot for m_can1 and 2 are not used. So anyway this wrong declaration should not change anything.

    So probably your Kernel is using u-boot dts to boot .... anyway, no issue here as now it works on your side.

    Visitor II
    February 29, 2020

    @Bernard PUEL​ Can you explain the proper way to generate device tree for stm32mp157c-dk2 board? For instance, I'm using the latest version of CubeMX (ver. 5.6.0) and:

    1. I select stm32mp157c-dk2 board in CubeMX board selector, then
    2. I click on initialize all hardware to their default values, then
    3. Enable FDCAN1 (disabled by default) for CortexM4, go to pins and define pin PA12 alternative function as FDCAN1_TX.
    4. Enable FDCAN2 (disabled by default) for CortexA7NS, go to pins and define pin PB12 alternative function as FDCAN2_RX.

    When I generate the code, in the project directory there's nothing got created under DeviceTree directory, but I can see some device tree file created under CA7/DeviceTree directory. Should I use the device tree from CA7/DeviceTree directory for this project?

    I've tried to compile it, but got the following error:

    bash-4.4# dtc -I dts -O dtb stm32mp157c-mp1-cubemx-fdcan1-only-mx.dts > stm32mp157c-mp1-cubemx-fdcan1-only-mx.dtb

    Error: stm32mp157c-mp1-cubemx-fdcan1-only-mx.dts:12.1-9 syntax error

    FATAL ERROR: Unable to parse input tree

    bash-4.4# head -22 stm32mp157c-mp1-cubemx-fdcan1-only-mx.dts

    /* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */

    /*

     * Copyright (C) STMicroelectronics 2020 - All Rights Reserved

     * Author: STM32CubeMX code generation for STMicroelectronics.

     */

    /* For more information on Device Tree configuration, please refer to

     * https://wiki.st.com/stm32mpu/wiki/Category:Device_tree_configuration

     */

    /dts-v1/;

    #include "stm32mp157c.dtsi"

    #include "stm32mp157cac-pinctrl.dtsi"

    #include "stm32mp157c-m4-srm.dtsi"

    /* USER CODE BEGIN includes */

    #include <dt-bindings/input/input.h>

    #include <dt-bindings/mfd/st,stpmic1.h>

    #include <dt-bindings/rtc/rtc-stm32.h>

    /* USER CODE END includes */

    / {

    bash-4.4# ls -la stm32mp157c.dtsi

    -rw-rw-r-- 1 1001 1001 51226 Feb 29 11:20 stm32mp157c.dtsi

    bash-4.4# ls -la stm32mp157cac-pinctrl.dtsi

    -rw-r--r-- 1 1001 1001 1500 Feb 29 11:20 stm32mp157cac-pinctrl.dtsi

    bash-4.4# ls -la stm32mp157c-m4-srm.dtsi

    -rw-r--r-- 1 1001 1001 25607 Feb 29 11:20 stm32mp157c-m4-srm.dtsi

    bash-4.4# ls -la dt-bindings/input/input.h

    -rw-rw-r-- 1 1001 1001 538 Jan 9 04:19 dt-bindings/input/input.h

    bash-4.4# ls -la dt-bindings/mfd/st,stpmic1.h

    -rw-r--r-- 1 1001 1001 1180 Feb 29 11:20 dt-bindings/mfd/st,stpmic1.h

    bash-4.4# ls -la dt-bindings/rtc/rtc-stm32.h

    -rw-r--r-- 1 1001 1001 249 Feb 29 11:20 dt-bindings/rtc/rtc-stm32.h

    Any idea what I'm doing wrong here?

    -albertr

    Visitor II
    February 29, 2020

    Ok, I realize that I need to use gcc to process all these include files, but what is the right syntax to execute it?

    bash-4.4# gcc -I dt-bindings/input -I dts -I . -x assembler-with-cpp -o stm32mp157c-mp1-cubemx-fdcan1-only-mx.tmp stm32mp157c-mp1-cubemx-fdcan1-only-mx.dts

    In file included from stm32mp157c-mp1-cubemx-fdcan1-only-mx.dts:17:

    ./dt-bindings/input/input.h:13:10: fatal error: linux-event-codes.h: No such file or directory

     #include "linux-event-codes.h"

             ^~~~~~~~~~~~~~~~~~~~~

    compilation terminated.

    -albertr

    Visitor II
    February 29, 2020

    Ok, I have figured out how to compile it. Basically, I've just added the new dts file produced by CubeMX to the Makefile in the linux-4.19.94/arch/arm/boot/dts directory and then executed `make dtbs` and it there was it.

    -albertr

    Visitor II
    April 9, 2020

    Hi, I'm having some issues to make FDCAN working on Cortex-M4, could you please share your sources?

    Thank you!

    Kind Regards

    Andrea

    Visitor II
    April 22, 2020

    Hi, Artem,

    could you share you source code(especially the code of M4 in STM32CubeIDE  & the dts files of linux system) on the github.

    on my board, the FDCAN1 can work in ​engineering mode. I use the STM32CubeIDE to generate the ELF file, then I copy the ELF file to the linux system , and run the ELF file by the shell, but it can't work.

    thanks!

    best regards