SPI clock problem in ConnectCore 6

Question

Hi,

I wanted to run an SPI example application on ConnectCore 6, the one from Linux kernel documentation:
https://www.kernel.org/doc/Documentation/spi/spidev

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.

Thanks in advance for any info on the problem.

Answer 1

Can you please try below commands in U-boot to ensure you hardware is operational?
These are the commands in Uboot to configure the SPI interface and transmit data:
• echo configure IOMUX mode
• mw 020e0090 1
• mw 020e0094 1
• mw 020e0098 1
• mw 020e008c 1
• mw 020e0208 5
• echo configure IOMUX daisy chain
• mw 020e07F4 0
• mw 020e07F8 0
• mw 020e07FC 0
• echo Configure SPI interface Master, SS0 high active, 32bits, 500KHz
• mw 02008008 01f05411
• mw 0200800c 00000000
• echo Write data to transfer
• mw 02008004 55555555
• echo Start transfer
• mw 02008008 01f05415

With these commands I see the SPI clock and SPI data on the oscilloscope.

Comments

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
[10f13980] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in: ath6kl_sdio(O) cfg80211(O)
-------------------------------------------------------------
U-Boot errors:
-------------------------------------------------------------
U-Boot 2013.04 - dub-2.3.0.3-git-g1bca652 (Nov 14 2014 - 16:05:14)

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
CPU:   Temperature 34 C, calibration data: 0x5824e869
Reset cause: POR
I2C:   ready
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
-------------------------------------------------------------
U-Boot 2013.04 - dub-2.3.0.3-git-g1bca652 (Nov 14 2014 - 16:05:14)

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
CPU:   Temperature 28 C, calibration data: 0x5824e869
Reset cause: POR
I2C:   ready
DRAM:  1 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Using default environment

In:    serial
Out:   serial
Err:   serial
Board: ConnectCore 6 SBC (undefined version)
Boot device: esdhc2 (uSD card)
PMIC:  DA9063, Device: 0x61, Variant: 0x50, Customer: 0x00, Config: 0x56
Net:   FEC [PRIME]
Hit any key to stop autoboot:  0
reading boot.scr
583 bytes read in 16 ms (35.2 KiB/s)
## Executing script at 12000000
reading uImage
4206656 bytes read in 205 ms (19.6 MiB/s)
reading imx6q-ccimx6sbc.dtb
51277 bytes read in 20 ms (2.4 MiB/s)
## Booting kernel from Legacy Image at 12000000 ...
   Image Name:   Linux-3.10.54-dey+gb1b3828
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4206592 Bytes = 4 MiB
   Load Address: 10800000
   Entry Point:  10800000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
=>

Answer 2

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 [1].

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,
Alex

[1]

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:

1) Build the spidev test application from a DEY-1.6 project:

bitbake dey-examples-spidev
scp tmp/work/ccimx6sbc-dey-linux-gnueabi/dey-examples-spidev/1.0-dey.r0/deploy-rpms/ccimx6sbc/dey-examples-spidev-1.0-dey.r0.0.ccimx6sbc.rpm root@192.168.x.y:/

2) Install on the target:

smart install /dey-examples-spidev-1.0-dey.r0.0.ccimx6sbc.rpm

3) Run the test application without the loopback cable:

spidev_test -D /dev/spidev32766.0
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)

00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00

4) Run the test application with the loopback cable:

spidev_test -D /dev/spidev32766.0
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)

FF FF FF FF FF FF
40 00 00 00 00 95
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
DE AD BE EF BA AD
F0 0D

5) Measure the SPI clock for the transfer:

Comments

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?

Answer 3

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.

Comments

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)

hdmi_hdcp
pinctrl_hdmi_hdcp_2: hdmihdcpgrp-2 {
            fsl,pins = <
                MX6QDL_PAD_EIM_EB2__HDMI_TX_DDC_SCL 0x4001b8b1
                MX6QDL_PAD_EIM_D16__HDMI_TX_DDC_SDA 0x4001b8b1
            >;
        };

i2c2 {
        pinctrl_i2c2_1: i2c2grp-1 {
            fsl,pins = <
                MX6QDL_PAD_EIM_EB2__I2C2_SCL 0x4001b8b1
                MX6QDL_PAD_EIM_D16__I2C2_SDA 0x4001b8b1
            >;
        };

If weim was a concern, then MOSI and MISO pins wouldn't work either, they are also included there. i2c2 uses different pin configuration that doesn't invoke EIM_D16

&i2c2 {
    clock-frequency = <100000>;
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_i2c2_2>;
    status = "okay";
};

The only left possibility is hdmi_hdcp, but it is not defined in any file (contrary to &hdmi_core or &hdmi_video).

--edit: hdmi uses non-conflicting pin configuration, so this is not an issue.

Is it enough to check the .dts files or should I look somewhere else for drivers conflict?

Answer 4

dey-1.6.1 was an EA release. All the others problems should be fixed with dey-1.6.2.

Answer 5

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.

Cheers,
Tomasz

Answer 6

if you are experiencing random crashes with default prebuilt images you probably should RMA your module

Comments

I have downloaded prebuilt images from digi ftp server, same problem for both eMMC and SD card images, so I will RMA the module.

Thank you for all your answers.

Best wishes,
Tomasz