When I connect to the SPI connector with an oscilloscope and run the application I can see that SS0 is pulled-down, there is transmission on the MOSI pin, but there is no clock on the SPI1_CLK pin.
Has anyone of you experienced such a problem? Any hints whether it is a hardware or software related problem? I would exclude a problem with a probe (e.g. shorting one of the pins) as I checked the SPI with two different devices.
which Pins on the board are you using? did yo check board schematics? are there any jumpers? is SPI_CLK pin multiplexed with other functionality? in such case the other driver should be disabled in kernel.
I work on an unmodified development board from Digi, ConnectCore6 SBC with unmodified kernel. I use only Ethernet and SPI through the expansion connector. There is one jumper that is responsible for choosing boot source (eMMC vs SD card). I checked the board schematics and it doesn’t seem to affect the SPI. SPI1_CLK is connected to EIM_D16 pad, SPI1_MISO/MOSI to EIM_D17/D18, SPI1_SS0 to EIM_EB2.
I’m new to embedded linux so I’m not sure how to check pin multiplexing and how to disable drivers in kernel, but I looked into .dts and .dtsi files. In imx6q-pinfunc.h I’ve found the following entry: #define MX6QDL_PAD_EIM_D16__EIM_DATA16 0x090 0x3a4 0x000 0x0 0x0
It seems to be pointing to the correct registers and assigns corrects values (checked with iMX6 reference manual).
EIM_D16 can also be used in hdmi_hdcp, i2c2, weim, judging by the entries in &iomuxc (imx6qdl.dtsi)
There was a reported failure on the SPI interface with dey-1.6.1 which was fixed on dey-1.6.2. I verified dey-1.6.2 once again and below is the process I followed .
dey-1.6.2 should get SA approval in the next week or so, so even if it won’t be officially released yet (not until the ECO is approved), we could provide it adhoc to customers with problems after the SA approval.
Hope it helps,
One setup to test it is to connect the MOSI and MISO pins with a loopback cable and use the spidev_test application provided with DEY to send a data pattern. We can then check the SPI clock for the transmission.
What I did is:
Build the spidev test application from a DEY-1.6 project:
Ok, so I’m waiting for dey-1.6.2. I followed the same procedure, I get the same results, but there is simply no signal on CLK pin.
Is the list of fixed issues in dey-1.6.2 available on-line? I have a couple more problems and I would be glad to know whether they are addressed in a new release or not. Is there some mailing list for DEY?
I downloaded dey-1.6.2, recompiled everything but still there is no SPI clock signal.
Have you run spidev_test application while checking the SPI_CLK pin with an oscilloscope?
Moreover I have a problem with ethernet which is somehow similar to this one: https://community.freescale.com/thread/322882
“After a while (most of the time a couple of minutes), we see that the i.MX6 board stops replying to the pings from the Linux PC”, but the RX packets counter in 'ifconfig" increments.
I had this problem before update, but after update I am not able to make ethernet working even for a while. Luckily Wi-Fi works fine.
Until now I was booting the system only from the sd card where I experienced the SPI problem. After some time I switched to boot from eMMC and the problem was gone - I could see the SPI clock in transmission under Linux. Anyway I tried your Uboot commands, it worked both in eMMC boot mode and SD Card.
After that I tried running SPI from Linux in SD card boot mode and… it also worked. I don’t know what exactly has changed, but now it works.
Unfortunately I have a problem with eMMC and/or SD card controller.
Either when I boot from eMMC (with or without sd card inserted) or sd card, Linux crashes after some time (even when doing “nothing”). The crash may occur also in U-Boot. When I reset after the crash, U-Boot cannot start. The crash occurs even when I switch back to dey-1.6.1.
Do you have any idea where to look for a solution? Is it something wrong with the hardware, or Linux/U-Boot software? I have updated all the sources, repartitioned eMMC, used a new SD card, updated U-Boot, nothing helps…
Linux crash messages:
ath6kl: ath6kl_htc_rx_process_hdr(): lk_ahd mismatch! (pPkt:0xa88f4640 flags:0x0)
ath6kl: failed to get pending recv messages: -12
Unable to handle kernel paging request at virtual address 10f13980
pgd = 80004000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in: ath6kl_sdio(O) cfg80211(O)
CPU: Freescale i.MX6Q rev1.5 at 792 MHz
CPU: Temperature 34 C, calibration data: 0x5824e869
Reset cause: POR
DRAM: 1 GiB
MMC: Card did not respond to voltage select!
Warning: failed to get sys storage device
FSL_SDHC: -1, FSL_SDHC: 0
Card did not respond to voltage select!
MMC init failed