No SPI communication on iMX7D+Aster but the same code works on Colibri Evaluation Board + iMX7D

I am attempting to get a spi slave device (MAX31865) working on the Aster board. The application code to read temperature from the MAX31865 has been working on a custom built kernel on the Colibri Evaluation Board. To enable spidev on the Colibri Evaluation Board the MCP CAN controller was disabled and spidev was set to “okay” in the device tree. Using SPI_MODE_0, I am able to communicate to the MAX31865 as expected.

Since the Aster board by default had (2) spi ports available no change was necessary (it seems). When I connect the SPI device (MAX31865) to the Aster spidev2.0 (X18) on a scope I see that CS is asserted and SCLK is generated along with a words I am sending but no response from the slave device (note this same device works when I connect it to the Colibri Eval board !).

I have tried multiple Aster boards with similar results (i.e. I don’t think this is unique to a particular board).

Is there difference between when an imx7d is used with Aster vs. Colibri Eval Board? Any other suggestions of what I should be checking?

Aster device tree (default) is below:

&ecspi3 {
	fsl,spi-num-chipselects = <2>;
	cs-gpios = <
		&gpio4 11 GPIO_ACTIVE_HIGH
		&gpio4 23 GPIO_ACTIVE_HIGH
	>;
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs &pinctrl_gpio5>;
	status = "okay";

spidev0: spidev@0 {
	compatible = "toradex,evalspi";
	reg = <0>;
	spi-max-frequency = <23000000>;
};

spidev1: spidev@1 {
	compatible = "toradex,evalspi";
	reg = <1>;
	spi-max-frequency = <23000000>;
    };
 };

Colibri Evaluation Board device tree below:

&ecspi3 {
status = "okay";

mcp2515: can@0 {
	compatible = "microchip,mcp2515";
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_can_int>;
	reg = <0>;
	clocks = <&clk16m>;
	interrupt-parent = <&gpio5>;
	interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
	spi-max-frequency = <10000000>;
	vdd-supply = <&reg_3v3>;
	xceiver-supply = <&reg_5v0>;
	status = "disabled";
};

spidev0: spidev@0 {
	compatible = "toradex,evalspi";
	reg = <0>;
	spi-max-frequency = <23000000>;
	status = "okay";
   };
};

Did you change U-Boot environment variable to use aster DTB when test you setup on Aster board?

We have determined a possible root cause :

In a nutshell, the level shifting on X18 is a problem for SPI communication to our slave devices. Supply input was kept at 3.3VDC (VIN @ 5VDC made no difference). Our short term action is to move the SPI bus to the X20 connector and change code to reference /dev/spidev2.1 however, there seems to be a signaling issue on the Aster board related to the level shifting.

Once we moved the SPI bus to X20, all devices worked as expected.

yes, i did change the u-boot environment variable to use the Aster dtb and verified that the Aster dtb is being loaded.

HI @cd25

Thanks for your Input.

If you move Spi signals to X20, then you will have 3.3V Level on these signals.

however, there seems to be a signaling issue on the Aster board related to the level shifting.

What is the issue?
Do you need a different voltage level than 3.3V in your design?

Best regards,
Jaski

Yes, 3.3V signal levels on X20 work as expected with our slave SPI devices. However, it is not clear why X18 SPI signals do not work? Aren’t the X18 signals also configurable to 3.3V using JP2?

Yes, you can switch SPI to 3.3V using JP2 however it slightly increases a delays introduced by level shiftier. Could you try to decrease SPI frequency and test SPI on X18?

Hi @cd25, @alex.tx,

Bit late, but I got Aster board quite recently.

Those bidirectional level shifters with automatic direction detection are interesting, but they are very picky regarding pull ups and pull downs on receiver side. I had to revisit DT settings to disable pull devices on input pins wired to these shifters. With pull up/down enabled unwanted short pulses appeared. External driver with open drain output and pull up resistor had to be reconfigured to push-pull mode. Universality is not always free…

On some other unrelated dev kit it was an issue caused by too big capacitance on receiver side of bidirectional level shifter… As I remember some delayed pulse appeared on MCU output driving such bidir shifter…

It would be nice to have Aster and other affected board datasheets updated with advices or notes on how to interface those level shifted pins, both inputs and outputs. Perhaps there is some good Application Note for his. Since I didn’t use such devices in my designs, I don’t know about such AN’s.

Edward

Thank you for sharing. Wi will take a look to this issue.