Embedded Linux (i.MX6)- accessing SPI GPIOs individually

Go To Last Post
2 posts / 0 new
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I'm not sure anyone will be able to help me but I am gonna throw out this Hail Mary-pass as I am getting brick-walled on the NXP forums. This is a bit long so bear with me.


I have an i.MX6 SoC and I am trying to work with the Linux system to enable a peripheral. The thing with this peripheral is that it requires a special procedure to be put into "SPI mode":


 - Reset the device

 - When CSPI_ready goes high enable SS
 - Send at least 16 clock cycles

 - Device should now be in SPI-mode


I have configured my Linux device tree pinmux GPIOs for /dev/spidev0.0 as follows:

pinctrl_ecspi1: ecspi1grp {
		fsl,pins = <
			MX6QDL_PAD_EIM_D18__ECSPI1_MOSI		0x0b0b0
			MX6QDL_PAD_EIM_D17__ECSPI1_MISO		0x0b0b0
			MX6QDL_PAD_EIM_D16__ECSPI1_SCLK		0x0b0b0
			MX6QDL_PAD_GPIO_19__ECSPI1_RDY		0x0b0b0
			MX6QDL_PAD_EIM_EB2__GPIO2_IO30		0x0b0b0 /* SPI CS0 */
			MX6QDL_PAD_EIM_D19__GPIO3_IO19		0x0b0b0 /* SPI CS1 */



As you can see - this works with some sort of "extended SPI" protocol.

(https://www.nxp.com/docs/en/refe... check out the chapter on ECSPI starting from pg. 118)


My first question: From my understanding according to page 119 of this manual - ECSPI is some underlying driver and I can just use the usual Linux SPI-driver to talk through this SPI-port i.e. #include <spidev.h> in my code and use the usual stuff. Is this correct or do I need to use some imx-specific spi-functions? I've tried to google imx-spi examples but absolutely nothing comes up in terms of examples. Furthermore, reading the chapter lead me to believe that imx-spi.c runs "under the hood" and makes whatever changes that are required to make the usual spi.c do it's work on an i.MX SoC.


Second question: Is it possible to access CSPI_RDY from /dev/spidev0.0 somehow or do I have to bind it to a GPIO in Linux? What I'd like to do, obviously, is to poll the CSPI_RDY pin and then initiate a transfer when a signal is detected on it.


Third question: if I initiate a transfer to send the minimum required 16 clock signals - won't there be a break between byte 1 and 2 on the clock - thus not initializing the device? Is it possible to just enable to clock signal through /spi/spidev0.0 somehow?


I tried to send a uint32_t just to get 32 clock signals (it's ok if it goes over 16) but it doesn't seem to be possible to send 32-bit data. I should point out that once the device is operational in SPI-mode it will take regular 8-bit data.

uint32_t trashData = 0xFFFFFF;

void spi_transfer(int fd, uint8_t *data, int length) {
	struct spi_ioc_transfer tr = 
		.tx_buf = (unsigned long) &trashData,
		.rx_buf = (unsigned long) &trashData,
		.len = 1,
		.speed_hz = DEVICE_SPEED,
		.bits_per_word = 32, //to send 32 clock pulses

	if(ioctl(fd, SPI_IOC_MESSAGE(1), tr) < 0) {
		perror("Error transfering data over SPI bus");


Sorry if this is asking a lot. I'm hoping some Linux wizard will come along.


Thanks in advance.




  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is Microchip and AVR forum, not NXP forum.no