Dear all,
I'm using following kind of Kernel ver. with i.MX6DL.
https://github.com/Freescale/linux-fslc/tree/4.14-1.0.x-imx
I'm facing SPI communication problem.
At the first packet of SPI communication, SPI_CLK become High↑ after CS becomes Low ↓.
That's why the MSB bit always becomes "1".
Send data "14 00 00 10 FF" -> 0b1 + 0x14 + 0x00 + ... -> Receive data "8A 00 00 08 7F"
With another CS device , we can see same phenomenon for the first packet.
Send data "00 00 xx" -> 0b1 + 0x00 + 0x00 -> Receive data "80 00 xx"
For the same device, there is no problem from 2nd packet as long as I checked.
But I don't know the root cause of this phenomenon, and when this problem happen.
In my environment, there is no EVK board, so this problem can be seen only with my own board with SPI1_cs1, cs2, cs3, SPI2_cs2.
Is there any way to avoid this problem?
Best regards,
Hi Nanao
may be recommended to test with official nxp kernels from
source.codeaurora.org/external/imx/linux-imx repository:
Linux 5.4.3_1.0.0 Documentation
mxc_spi_test\test - imx-test - i.MX Driver Test Application Software
"linux-fslc" kernels are supported by community and issue may be posted
on meta-fsl-arm mailing list
meta-freescale@lists.yoctoproject.org | Home
Differencies between kernels are described on
difference between Yocto Community BSP and Freescale BSP Release
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi igorpadykov,
Thank you for your comment.
I checked the Kernel ver. again, and found that the correct ver. is following one.
https://source.codeaurora.org/external/imx/linux-imx/?h=imx_4.14.98_2.0.0_ga
Could you please give me any other advice?
Best reagrds,
Nanao.
Hi Nanao
also one can test with baremetal sdk test (folder ../drivers/spi), then compare
ecspi settings with linux. "1.1.0_iMX6_Platform_SDK.zip"
on link SMP Enable in IMX6
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi igorpadykov,
Thank you for your reply.
Now it's difficult to test with baremetal sdk test with my environment.
By the way, I found the another thread and it looks like similar problem.
i.MX6 ecspi race condition with CPOL=1 and CS GPIO
Our Ver. is later than "imx_4.14.78_1.0.0_ga release".
Do you know there is any other patch?
Best regards,
Nanao.
Hi igorpadykov,
We found that this issue happen with SPI Mode3.
If I changed the setting from Mode3 to Mode0, CLK and data are no problem.
And I tried adding 50us delay as Théo mentioned at i.MX6 ecspi race condition with CPOL=1 and CS GPIO
/* CTRL register always go first to bring out controller from reset */
writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
udelay(50);
reg = readl(spi_imx->base + MX51_ECSPI_TESTREG);
if (spi->mode & SPI_LOOP)
reg |= MX51_ECSPI_TESTREG_LBC;
else
reg &= ~MX51_ECSPI_TESTREG_LBC;
writel(reg, spi_imx->base + MX51_ECSPI_TESTREG);
writel(cfg, spi_imx->base + MX51_ECSPI_CONFIG);
But it does not have good effect for my case. (Our speed is 3MHz.)
This slave device can used only with SPI Mode 3, so I cannot change Mode.
At least we would like to know if this issue happen only for the first packet or not.
If someone knows that this is a known issue, please let us know.
Best regards,
Nanao Akimichi.
HI Nanao
one can try with Sabre-AI image imx6dl-sabreauto-ecspi.dts :
imx6dl-sabreauto-ecspi.dts\dts\boot\arm\arch - linux-imx - i.MX Linux kernel
try to work without dma (remove dma entries in ecspi1: ecspi@02008000 {..)
imx6qdl.dtsi\dts\boot\arm\arch - linux-imx - i.MX Linux kernel
Best regards
igor
Hi igor,
Without dma doesn't work, however, we can see that the wrong timing issue disappear by adding following 3 lines.
u32 sclk_val = 15;
writel(MX51_ECSPI_CTRL_ENABLE | MX51_ECSPI_CTRL_MODE_MASK, spi_imx->base + MX51_ECSPI_CTRL);
writel(sclk_val << 20 | sclk_val << 4, spi_imx->base + MX51_ECSPI_CONFIG);
This will be a temporary solution for us.
If there is another official solution, let us know.
Thank you for your help.
Best Regards,
Nanao Akimichi.
Hi Nanao
I will check internally and send details via mail.
Best regards
igor