2
\$\begingroup\$

I have connected SPI flash to my linux board (imx 233 based) running in it's SPI bus. I have configured kernel, and SPI bus and flash chip to it.

The flash is currently on a breadboard. Before trying to work on linux, I tried separately and I'm able to read and write as I like with a FT2232H chip (FT2232 breakout board by dangerousprototypes.com). However, linux-board, I had to add pull-up resistors (10k) in the data in and data out lines, the chip was not recognized correctly otherwise.

My actual problem is that now I'm trying to just read raw flash through mtd driver, and everything seems correct, if I read less than 35 bytes. Immediately if I read more than 35 bytes (36 or more), the driver complains about DMA error:

[  521.700000] mxs-spi 80034000.ssp: DMA transfer timeout
[  521.700000] spi_master spi32766: failed to transfer one message from queue

Also when this happens, most of (if not all) the bytes will be incorrect.. Reading less than 35 bytes will return "immediately" (no timeout), and all bytes read will be correct.

My C code is straight from MTD read example:

int main(int argc, char * argv[])
{

    if (argc != 2)
    {
    printf("Need arguments how many chars to read\nExiting...\n");
    return 1;
    }

    int amount = atoi(argv[1]);
    printf("reading (%d) chars\n", amount);

    mtd_info_t mtd_info;
    int fd = open("/dev/mtd0", O_RDONLY);
    ioctl(fd, MEMGETINFO, &mtd_info);

    printf("MTD type: %u\n", mtd_info.type);
    printf("MTD total size : %u bytes\n", mtd_info.size);
    printf("MTD erase size : %u bytes\n", mtd_info.erasesize);

    /* read buffer */
    unsigned char buf[amount];

    read(fd, buf, sizeof(buf));

    int i = 0;

    for (i = 0; i < amount; i++)
    {
            printf("%i: %X\n",i,buf[i]);
    }
return 0;
} 

The timeout happens "as expected" (10 seconds) in spi-mxs.c:

drivers/spi/spi-msx.c:
static int mxs_spi_txrx_dma(...):
....
ret = wait_for_completion_timeout(&spi->c, msecs_to_jiffies(SSP_TIMEOUT));

Any ideas what might be wrong ? I'm not that good with electronics, so please all suggestions are welcome.

\$\endgroup\$
4
  • \$\begingroup\$ If you have an oscilloscope, that will show you what's going on on the data/clock lines. \$\endgroup\$
    – John U
    Dec 19, 2012 at 13:20
  • 1
    \$\begingroup\$ On the software side, a possible reason you are seeing bad data is not because anything was corrupt, but because the read system call returned -1. You ignore the return value, and so in that case your loop prints uninitialized data from the variable-length array. \$\endgroup\$
    – Kaz
    Dec 19, 2012 at 16:47
  • \$\begingroup\$ might be a clocking issue, try lowering clock speed and see it if helps. Later, when you move from breadboard you might be able to increase clock rate. \$\endgroup\$
    – miceuz
    Dec 19, 2012 at 17:31
  • \$\begingroup\$ John, I do have oscilloscope, and I will check what I can see from it.. But, the memory is limited, and usually one can only see the first couple messages. Kaz, you are 100% right, I should check it.. though still the problem is somewhere below the read funtion. Miceuz, thanks for your suggestion, I will see about it.. \$\endgroup\$
    – julumme
    Dec 20, 2012 at 2:42

2 Answers 2

1
\$\begingroup\$

I think it is a problem with the SPI driver. Does it still not work with 3.7 upstream kernel? There were a lot of fixes applied there.

\$\endgroup\$
2
  • \$\begingroup\$ Hi Marex, Indeed I'm working on the upstream driver (as per our discussion in Freescale forums), I will try your suggestions from there, and let's see if I can help you with investigation on the root cause! thanks! \$\endgroup\$
    – julumme
    Dec 21, 2012 at 3:21
  • \$\begingroup\$ patchwork-mail1.kernel.org/patch/1910641 Patch is not present on Linux 3.8.4 but has been added to Linux 3.9.4. \$\endgroup\$
    – spearson
    May 30, 2013 at 18:27
2
\$\begingroup\$

This is not an electronics problem. On a SPI bus, the master is in complete control of the timing of any transfer that is initiated. In particular, on a read operation, the slave device can return bad data or no data at all, but it can't affect whether or not the transfer completes.

In other words, the DMA timeout error you're getting is entirely an issue within the Linux kernel or the specific driver you're using. In any case, a more specific answer is going to require a lot more detail from you: What flash chip are you using? What CPU board are you using? What Linux distribution are you using? What are the version numbers of the kernel and any kernel modules and/or device drivers you're using? Do you have links to where these items can be found?

\$\endgroup\$
4
  • 2
    \$\begingroup\$ That's not the complete story though; while the slave cannot change the timing of an individual transfer, a complete operation may include polling the slave's status, and waiting for that to reach a ready state can delay things. \$\endgroup\$ Dec 19, 2012 at 16:24
  • 1
    \$\begingroup\$ It's a fair point, but that wouldn't show up as a "DMA timeout" (i.e., at the hardware transfer level), it would be identified as a higher-level protocol timeout of some sort. \$\endgroup\$
    – Dave Tweed
    Dec 19, 2012 at 17:08
  • \$\begingroup\$ Dave, thank you very much for your reply! My flash chip is SST25VF064 (Microchip), and it's connected to Olinuxino maxi board (from Olimex). I don't use any particular distribution, but I'm building a simple filesystem based on busybox. The linux version is 3.7, it's latest one from Freescales mainline (github.com/Freescale/linux-mainline/branches). \$\endgroup\$
    – julumme
    Dec 20, 2012 at 2:45
  • \$\begingroup\$ Also, I'm really a new to this, so I might as well have some newbie mistake somewhere.. Currently, I have only defined my chip in dtsi, and added support for this particular flash chip to m25p80.c (only 32Mbit flash was there, I just checked the JEDEC from datasheet (0xbf254b), and doubled the amount of sectors to 128, I wonder if that is correct?) \$\endgroup\$
    – julumme
    Dec 20, 2012 at 2:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.