Verdin iMX8M Plus - SPI2 port signal integrity issue


I’m trying to use the the ECSPI2 on out Verdin iMX8M Plus and I ran into signal integrity issue. I’m trying to run the SPI bus at 10MHz and the output as a really slow ramp up and is only usable at around 1MHz speed. The iMX should be able to run up to 40MHz. Below is a look at the signal. This the direct output of the SOM. We tried almost all variation of the the I/O config in the device tree and can’t get a better signal. Other I/Os used have sharp rising edge. Any idea on what setting could be wrong?

From DTS:

pinctrl_ecspi2: ecspi2grp {
	fsl,pins = <
		MX8MP_IOMUXC_ECSPI2_SS0__GPIO5_IO13		0x1c4	/* SODIMM 128 */

Signal snapshot:

Just to add some more information I see the same behavior on the Verdin EVB if I look at the signal on X52 (pin 21 and 33)
Also definition in the DTS:
/* Verdin SPI_2 */
&ecspi2 {
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = “default”;
pinctrl-0 = <&pinctrl_ecspi2>;
cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;

status = "okay";

spidev20: spidev@0 {
	compatible = "rohm,dh2228fv";
	reg = <0>;
	spi-max-frequency = <10000000>;
	status = "okay";


Hey @mara0209,

The hexadecimal field number after the pin can be modified. Specially you can adjust the slew rate (fast/slow) and drive strength. I think this may help your situation.

You can find more via the NXP documentation and search for field descriptions for your specific pin.
For the Verdin IMX8M Plus you would reference the I.MX 8M Plus Applications Processor Reference Manual (IMX8MPRM). You most likely have to make an NXP account and agree to some terms, but its a quick process. The Field chart is derrived from binary and then converted to hexidemical.


Hi Éric,

We did know about this (section of the IMX8MPRM) and basically tried all the possibility and don’t see any improvement. Could we me missing something?



Extra info, we tried the same setting as ECSP1 for the pin config and still got different result (SPI1 is working fine). Could we be missing something in the device tree that prevent the config to be applied?

Hi again Eric,

My team in Malaysia did some more test to confirm the setting does help a bit but not that much. What is very puzzling is they tried another set of SPI2 pin on the EVB (95-93-72-70) and the signal is MUCH better.


@eric.tx any suggestion on why the SPI signal is bad on some pins, even on the EVB?

Hey @mara0209,

I do not currently, are you able to send which pins you have tried on and received different results? And, on the pins that are working fine, does this meet your standard to be able to use?


Hey @mara0209,

Can you confirm which module you have? Specially if you have a module with or without bluetooth/wifi.


Do you mean Verdin Development Board? V1.1 schematic shows “stiching capacitors” of 1nF on all your bad pins. Is it the case?

@Edward yes they are there, bu 1nF won’t load the signal to create what I see (I don’t want to mess my EVB, but will do to be 100% sure). Also I see the exact same signal with my own board that don’t have any cap to GND.

1nF @ 10MHz isn’t nothing. I=C*dV/dt. Keeping in mind limited output current capability, which could be as high as 20mA for typical MCU, time to (dis)charge 1nF from/to 1.8V should be about 0.1us. 1nF is enormously high load for 10MHz.
I don’t know anything about your board. Aren’t you using level shifter IC’s with automatic I/O direction selection, those without I/O direction selection pins? Such devices may have interesting effects when receiving side has too high capacitance or even just a pull up/down, which may lead to unexpected toggle of I/O direction in some conditions.