Jetson Xavier NX mcp2515 issues

Robotics & Edge Computing Jetson Systems Jetson Xavier NX
,
1

Hi I have a custom carrierboard for Jetson xavier nx which has a MCP25625 Spi to can controller & tranciever and everytime i flash my modified pinmux and dtsi then it
Jetson Linux 34.1.1 JetPack 5.0.1

can_clock: can_clock {

    compatible = "fixed-clock";

    #clock-cells = <0>;

    clock-frequency = <16000000>;

    clock-accuracy = <100>;

};


spi@3210000{ /\* SPI1 in 40 pin conn \*/

    status = "okay";

    spi@0 { /\* chip select 0 \*/

        compatible = "microchip,mcp2515";

        reg = <0x0>;

        spi-max-frequency = <10000000>;

        clocks = <&can_clock>;

        interrupt-parent = <&tegra_main_gpio>;

        interrupts = <TEGRA194_MAIN_GPIO(Q, 1) 0x1>;

        controller-data {

            nvidia,enable-hw-based-cs;  

            nvidia,rx-clk-tap-delay = <0x10>;

            nvidia,tx-clk-tap-delay = <0x0>;

        };

    };

    spi@1 { /\* chip select 1 \*/

        compatible = "tegra-spidev";

        reg = <0x1>;

        spi-max-frequency = <50000000>;

        controller-data {

            nvidia,enable-hw-based-cs;

            nvidia,rx-clk-tap-delay = <0x10>;

nvidia,tx-clk-tap-delay = <0x0>;

        };

    };

};

image

SPI0 was untouched and the GPIO was configured like CS1 with 3.3V tolerance enabled, from what i’ve understood leaving the cells empty would be the same as N/A for the Master Slave Mode for example

pin 91 SPI0_SCK →1.8V/3.3V level shifter →MCP25625 SCK
pin 89 SPI0_MOSI →1.8V/3.3V level shifter →MCP25625 MOSI
pin 87 SPI0_MISO →1.8V/3.3V level shifter →MCP25625 MISO
pin 95 SPI0_CS0 →1.8V/3.3V level shifter →MCP25625 CS0
pin 212 (GPIO10) → MCP25625 INT

:~$ dmesg | grep mcp
[ 16.374311] mcp251x spi0.0: MCP251x didn’t enter in conf mode after reset
[ 16.374485] mcp251x spi0.0: Probe failed, err=16
[ 16.374600] mcp251x: probe of spi0.0 failed with error -16

The thing is that when i use another boards flash conf, which i based my board around then the MCP2515 initializes and even works, when i tested transmitting and recieving then it worked. Afterwards i flashed my own pinmux and dtsi onto the board and the mcp2515 chip locks out. And doesn’t work.

Since the mcp2515 did work at some point im wondering what could be the issue (most likely software)

After replacing the MCP25625 chip on the board then it then its the same error, previously i’ve tried replacing the levelshifter and crystal aswell but those fixes didn’t work either, like what could possibly be the thing that breaks here?

After measuring it seems like CS0 and MISO on the MCP25625 were shorted, Replacing all components: crystal, capacitors, MCP25625, and the levelshifter MISO and CS are not shorted anymore but the chip still won’t initialize with the same
[ 16.993959] mcp251x spi0.0: MCP251x didn’t enter in conf mode after reset
[ 16.994125] mcp251x spi0.0: Probe failed, err=16
[ 16.994224] mcp251x: probe of spi0.0 failed with error -16
errors

after adding HARDWARE RESET logic to MCP25625 then it started working again, but that begs the question, is there something wrong with the dtsi and pinmux i posted above?

image
image1666×739 120 KB

3

Hi h15485545,

Do you want to use MCP25625 or MCP2515 on your custom carrier board?

It is such an old release.
Could you verify with the latest Jetpack 5.1.6(L4T r35.6.4)?

If MCP2515 can work as expected on your board before, please clarify what modification may cause the current issue.

4

Im using MCP25625, and I’m not sure what could be causing that issue. One thing i might’ve narrowed down is to not leave the RESET pin floating and instead RC filter to it for a 2 us delay.
This is the configuration and the the oscillator is an external 16 MHZ crystal with 22 pF ceramic capacitors.

Im kind of leaning towards myself configuring the DTSI or PINMUX wrong somehow, but i’m not really sure where the issue could appear. The Interrupt pin is configured for Input, INT PU, Wake Pin - NO, 3.3V Tolerance Enable - Enable, LDPR - Disable, Master Slave Mode - Empty. The code above was the DTSI part used.

The diode used for discharning RESET is BAS516,115. I’ll try with the latest Jetpack aswell and see how it goes.

image
image934×883 37.5 KB

5

Do you mean MCP2515 working well but MCP25625 doesn’t?

I’m not sure if mcp251x driver can work with your MCP25625 module.
Please check this with your vendor.

7

RESET signals usually shouldn’t be left floating, but the documentation of the MCP25625 should be checked to verify the requirement. If you don’t want to directly control the RESET with a GPIO, usually an alternative is a pull up to the device’s VDD with a cap to delay the RESET vs the VDD.