Bad level signal on SPI with M4

Technical Support
, , , ,
1

Hi folks,
I have a problem reading data from an FPGA using SPI with the Cortex M4 with FreeRTOS.

I write 64 bytes to the FPGA first, and then I read 64byte. The SPI setting is:

uint32_t baudRate;
ecspi_init_config_t ecspiMasterInitConfig = {
   .mode = ecspiMasterMode,
   .burstLength = 255, //ECSPI_MASTER_BURSTLENGTH,
   .channelSelect = ecspiSelectChannel0, //BOARD_ECSPI_CHANNEL,
   .clockPhase = ecspiClockPhaseFirstEdge, // 0U   
   .clockPolarity = ecspiClockPolarityActiveHigh, // 0U  ,
.ecspiAutoStart = ECSPI_MASTER_STARTMODE
};

ecspiState.txBuffPtr = 0;
ecspiState.rxBuffPtr = 0;
ecspiState.txSize = 0;
ecspiState.rxSize = 0;
ecspiState.xSemaphore = xSemaphoreCreateBinary();

/ Update clock frequency of this module /
ecspiMasterInitConfig.clockRate = get_ecspi_clock_freq (BOARD_ECSPI_BASEADDR); 
PRINTF("\n\r\n\r Ecspi Clock Rate: %d\n\r", ecspiMasterInitConfig.clockRate);

baudRate = ECSPI_SetBaudRate (BOARD_ECSPI_BASEADDR, ecspiMasterInitConfig.clockRate, 1000000);
PRINTF(" Ecspi BaudRate: %d\n\r", baudRate);
ecspiMasterInitConfig.baudRate = baudRate;


/ Ecspi module initialize, include configure parameters /
ECSPI_MasterConfig (&ecspiMasterInitConfig);

But when SSP_CLK signal goes to 0 for reading the first bit, I have a “glitch” in the MISO.
It’s seems like an overcurrent in the MISO line (the first bit of the rx buffer is ever 1).
Please see the image (my apologies for the bad quality…):

glitch

The upper trace is the SPI CLK, the lower is the MISO.
The code is the same of FreeRTOS/examples/imx7d_val_m4/demo_apps/ecspi_flash_demo

Some hints ?
TIA

2

hi @Mane

Could you provide the version of the Bsp of your module?

Concerning your issue, could you provide the schematic of SPI connection between iMX7 and FPGA? What is your Spi Clock frequency?

According to your settings, the data from slave (MISO) is sampled at high state of the SPI Clock signal. So if there is glitch when the SPI Clock is Low, this should not create any issues.

Could you also add the Chip select line? Actually three lines are important to measure the SPI Communcation: SPI Clk, MISO and Chip Select.

Thanks and best regards
Jaski

3

Hi Jaski

The BSP version is the latest stable (2.8b3)

M4 is the Master, FPGA is the slave.
The connection is on the X3 connector of Colibri Evaluation Board (Rev 3.2) A30: SSP_FRM, B30: SSP_TXD, B31: GND, C29: SSP_CLK, C30: SSP_RXD) – the SPI compatible pins.

Ecspi Clock Rate: 24000000
Ecspi BaudRate: 1000000

I’ve done a similar test with two different iMX6 SOM (Both with WCE2013 and Linux), and the same with the iMX7 in Linux: all work very well.

But with the iMX7 with Linux (the SOM used with M4-test), when I connect the oscilloscope probe to the SPI Clock the communication fault, the data are all wrong; removing the probe, the data is ok.
With the two iMX6 I don’t have problem with the probe.

4

If the SPI Communication works well with Imx6 and Imx7 Linux, then the only thing which might be a Problem is the drive strength of the Pins. That’s why also the communication is wrong when you put the probe on the pins.
Did you set the same drive strength for M4 core as for the A7 core?

5

I can’t have modified the iomuxing of M4 and A7 Cores.

About A7 Core, in the imx7-colibri.dtsi file we have:

pinctrl_ecspi3_cs: ecspi3-cs-grp {
		fsl,pins = <
			MX7D_PAD_I2C2_SDA__GPIO4_IO11		0x14
		>;
	};

	pinctrl_ecspi3: ecspi3-grp {
		fsl,pins = <
			MX7D_PAD_I2C1_SCL__ECSPI3_MISO		0x2
			MX7D_PAD_I2C1_SDA__ECSPI3_MOSI		0x2
			MX7D_PAD_I2C2_SCL__ECSPI3_SCLK		0x2
		>;
	};

The value ‘0x2’, in the device tree customization,
is
1-0 DSE Drive Strength Field
00 - X1
01 - X4
10 - X2
11 - X6

And, sincerely, I can’t have found references about ‘10 - X2’ means in both Chapter 4 of the Toradex Colibri iMX7 data sheet and Chapter 8 of the NXP®/Freescale i.MX 7 application processor reference manual.

The same for M4 Core:

#define IOMUXC_SW_PAD_CTL_PAD_I2C2_SDA_DSE_MASK  0x3u
#define IOMUXC_SW_PAD_CTL_PAD_I2C2_SDA_DSE_SHIFT 0
#define IOMUXC_SW_PAD_CTL_PAD_I2C2_SDA_DSE(x)    (((uint32_t)(((uint32_t)(x))<<IOMUXC_SW_PAD_CTL_PAD_I2C2_SDA_DSE_SHIFT))&IOMUXC_SW_PAD_CTL_PAD_I2C2_SDA_DSE_MASK)

#define IOMUXC_SW_MUX_CTL_PAD_I2C2_SCL_MUX_MODE_MASK 0x7u
#define IOMUXC_SW_MUX_CTL_PAD_I2C2_SCL_MUX_MODE_SHIFT 0
#define IOMUXC_SW_MUX_CTL_PAD_I2C2_SCL_MUX_MODE(x) (((uint32_t)(((uint32_t)(x))<<IOMUXC_SW_MUX_CTL_PAD_I2C2_SCL_MUX_MODE_SHIFT))&IOMUXC_SW_MUX_CTL_PAD_I2C2_SCL_MUX_MODE_MASK)

And I don’t know if they have and how to set the same strength…

[EDIT]
I’ve found drive current values in a NXP community thread about IMX7 IBIS MODEL for SDIO :
drive currents

and for the A7 Core seems be 10,4mA …

6

Ok, I’ve solved the problem …

The A7 had the DSE set to 0x2 and the M4 core to 0x0 (5.2mA and 2.6mA).

Setting the M4-core pin strength of MISO and CLK both to 0x1 (10.4mA), the problem disappear.

Thanks!

7

Perfect that it works. Thanks for the feedback.