Using SPI with M4 in iMX7D

Technical Support
, , , ,
1

Hi,
I am using colibri iMX7 and trying to run the ecspi code from M4 core. I altered the device tree and disabled the ecspi3 completely. I checked with linux side , the ecspi bus (either can or spidev2.0) is not available in Linux. So, from this i can conclude that the device tree is implemented correctly. But the problem, when running this code in M4 core, the code gets struck in a infinite while loop in the function ECSPI_MasterTransfer.

  1. How to check wheather ecspi3 is enabled for the M4 core?
  2. The SPI pins are same for both M4 and A7 right?
  3. Is there any examples for running ecspi with M4 using freeRTOS?

Thanks for your time.
Regards,
Nishanth

2

I copied the example from the FreeRTOS imx7_colibri_m4 driver example and it worked on my platform no problem.

3

Dear @nishanth1829

As a general recommendation, you stop the boot process in U-Boot, when doing first tests with any M4 code. This way you can rule out any conflicts between Linux and FreeRTOS resource allocation, without even having to care about the device tree.

So all the configuration of the SPI is done by the M4. Typical problems are:

  • Clock not activated
    In this case the software might freeze or throw an exception as soon as you try to access an SPI register
  • Pins not configured properly
    Maybe you can find something by measuring the signals with an oscilloscope, and applying pull-up/down resistors. This is only a partial hint, but could give you an indication whether the polarity and direction of the signals is as expected.

Regards, Andy

4

Hi @andy.tx ,
I tried with stopping the u-boot by pressing any key during boot but the application in M4 is also not started. The M4 application starts only after u-boot. (I am not using FreeRTOS code, I am trying with the driver example)

you stop the boot process in U-Boot, when doing first tests with any M4 code

This means to stop the u-boot by pressing any key in the UART-A while booting right?

5

hello @nrcm ,
I am new to device tree alterations, I disabled ecspi3 in linux side but the SPI pins are accessed by alternate functions i think.So, I tried to disable them but i have completely no idea of which pins to disable.
What changes did you make in the device tree? If possible, can you share your device tree file ?

Thanks for your time,
Regards,
Nishanth

6

Yes, you need to stop in U-Boot, manually start M4 and check if the SPI Communication is working correctly and your code does not get stuck.

Best regards,
Jaski

7

Hi Jaski,
As you said, I stopped the linux in U-boot and manually started M4 Core and now the M4 code is running successfully. But I could not find any clock pulse generated in the pin SODIMM_88. The SPI pins are same for both iMX7 and M4 right?

Regards,
Nishanth

8

Dear @nishanth1829

The peripherals including the options for pin configuration are independent of the core which controls it.
After stopping your system in U-Boot, the M4 runs completely independent of any Linux code. So please verify that

  1. You are accessing the correct SPI instance which is connected to SODIMM_88
  2. The pin is configured correctly (alternate function, pull resistors etc).

Regards, Andy

9

Hi @andy.tx ,

You are accessing the correct SPI instance which is connected to SODIMM_88
Yes, I am accessing the same pin that I used for SPI CLK from Linux (SODIMM_88).
The pin is configured correctly (alternate function, pull resistors etc)
I tried by adding pull down resisitors but the SPI Clock is still not generated. Does the M4 also uses pin muxing?..If so how to configure those pins like doing with device tree for Linux?

Regards,
Nishanth

10

Dear @nishanth1829

Let me clarify the i.MX7 architecture:
The M4 and A7 are individual CPU cores, but all the peripherals except the core itself are shared. Therefore your question “Does the M4 also uses pin muxing?” should be rephrased to “Does the GPIO controller in the i.MX7 use pin muxing?”

Yes, the GPIO controller supports pin muxing, and this needs to be configured correctly. FreeRTOS is a much more light-weight OS compared to Linux, and does not support high-level features such as a device tree. You need to access the GPIO peripheral registers directly to configure the pin muxing. You can find the details about these registers in the i.MX7 Reference Manual.

Regards, Andy

11

Dear @andy.tx ,
Thanks for your explanation.

You need to access the GPIO peripheral registers directly to configure the pin muxing

I have initiated those pins as ECSPI3 by ECSPI_Init(BOARD_ECSPI_BASEADDR, &initConfig) . Is this alone not enough for configuring those pins?
Also , while debugging I could find that the initConfig.clockrate is always set to be zero by the function get_ecspi_clock_freq(BOARD_ECSPI_BASEADDR). I also checked with ECSPI1 and ECSPI2 still they are set to be zero.I am using the provided driver example ECSPI polling.

Regards,
Nishanth

12

Dear @nishanth1829

ECSPI_Init() only initializes the ECSPI controller. The pin muxing is configured in the function configure_ecspi_pins().

For the initConfig.clockrate, I recommend to step into the function get_ecspi_clock_freq(BOARD_ECSPI_BASEADDR). The function is rather small, so I think it should be easy to find the root cause. Maybe you call the function before the SPI is initialized, and the clock is really not yet activated?

Regards, Andy

13

Hi @nishanth1829

// UART2 used for M4 debug port
&uart2 {
	status = "disabled";
};

//SPI used on M4
&ecspi3 {
 status = "disabled";
};
14

hi @andy.tx ,
The problem was due to the mismatch of hardware_init.c file from our side. Once the correct file is used, I could use the SPI without any problem. Thank you very much for your support.
Regards,
Nishanth