i.MX6 ECSPI: MOSI and CS driven before transfer starts

[floriandoerfler]

Dear All

I have a problem with the behavior of ECSPI befor the start of a transfer and need a pointer where the problem could be. I did not find any clue in the manual that would explain what I am seeing.

First a little bit about my Setup:

I am using the i.MX6 ECSPI with a custom linux (3.0.35 Kernel) and the spidev interface. The internal Pull-Down is enabled for the MOSI pad. I tried both writing to the device file and sending through ioctl. I send 16 bit per word. It does not matter which SPI mode I use, I tried all.

My problem is the behavior of the MOSI pin before a transfer starts: The pin goes high for about the length of 3 clock cycles befor the actual transfer starts. Before the first clock, the pin goes to the correct level (depending on the data to be sent). The slave select signal is asserted during this time.

You can see the behavior in the attached image, the data sent is 0101111101011111, blue is MOSI, green is CLK, red is CS: CS goes low and MOSI goes high for some time, then MOSI goes low for the first bit and the clock starts:

So the question is:

Is this the expected behavior of the ECSPI block?

If not, what could be causing this behavior?

Best Regards

Florian Doerfler

[floriandoerfler · Accepted solution]

I have found part of the solution by inspecting the i.MX6Q Reference Manual: The DATA_CTL bits of the ECSPIx_CONFIGREG register define the inactive level of the data line.

To quote the Reference Manual chapter 21.7.4:

ECSPIx_CONFIGREG field descriptions

DATA CTL. This field controls inactive state of the data line for each SPI channel.

DATA CTL[3] is for SPI channel 3.

DATA CTL[2] is for SPI channel 2.

DATA CTL[1] is for SPI channel 1.

DATA CTL[0] is for SPI channel 0.

0 Stay high.

1 Stay low.

Setting the bit keeps the MOSI line low between assertion of CS and the start of the clock, so I can live with that.

But I still wonder:

• I still get one stray pulse on the first burst that I send
• Is there a way to get rid of this behavior alltogether?

[alejandrolozan1]

Hi,

I have to check with a scope about this. Are you getting a kind of error or weird behavior with the slaves?

Best Regards,

Alejandro

[floriandoerfler]

Hi Alejandro

I use the MOSI output of the SPI interface to modulate the carrier of an infrared interface. So the exact waveform of the signal is important.

However: I have found part of the solution in the manual (see separate post).

Cheers

Florian