Hi Edgar, Sorry, I was away a few days. Immediately prior to going away, I did indeed try that, as the polling overhead is no problem for me, and given that most transfers are only a few bytes, might actually be faster. It worked fine in a few quick trials, so I sent it to my client. He's been using it for 4-5 days with no problems, so your tip was certainly a good one!
Thanks for the help, -Bob On 10/5/07, Edgar Weigand <[EMAIL PROTECTED]> wrote: > Hey Bob, > > have you ever tried using SPI polling mode? > > ioctl(dev, QSPIIOCS_POLL_MOD, 1); // use polling mode only > > We also had racing conditions when using interrupts with SPI since > you're able to start a new SPI transfer before the last one has > been finished. > > Our system locked up exactly after 14hours in a simple app with 2 > SPI channels activ when using interrupt. Since we changed to > polling mode only we never had any unexspected system hangs due > to SPI. At the moment we use 5 SPI channels simultaneous in a > multithreaded app where the SPI is triggered from various trheads. > > Hope it helps, we are using uClinux 2.4.20 with MCF5282. I think the > actual mcf_qspi.c driver has changed meanwhile. > > Regards, > > Edgar > > -----Ursprüngliche Nachricht----- > Von: Bob Grimes [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 4. Oktober 2007 00:44 > An: uClinux Mailing List > Betreff: [uClinux-dev] Multiple channels on QSPI, using mcf_qspi.c > driver > > > I have been using the mcf_qspi.c QSPI driver on several mcf5329 > Coldfire boards, both the Freescale/LogicPD evaluation board and our > custom hardware, and it has largely worked fine - when using only one > minor device - specifically, minor number 0. However, now that I am > using several separate minor numbers, I get occasional, mysterious > hangs, but never on minor number 0! When I say "hangs", I mean that > the call to write never seems to return. > > For example, I open and use them something like this: > > int dev0; > int dev5; > ... > > int main(...) { > ... > dev0 = open("/dev/qspi0", O_RDWR); > dev5 = open("/dev/qspi5", O_RDWR); > ... > printf("Writing 0\n"); > numWritten0 = write(dev0, outbuffer0, num0); > printf("Writing 5\n"); > numWritten5 = write(dev5, outbuffer5, num5); > printf("Finished writing\n"); > ... > > Here is the output: > > Writing 0 > Writing 5 > > Note, no "Finished writing". If I break out of the code (while using > a BDM debugger), the processor is almost always in the idle task - in > other words, the rest of the system seems fine. > > The first write _always_ works - at least, I've never seen it fail. > The second write, however, fails more often than not, but it does > succeed 20-30% of the time. The order of the writes don't matter > either. However, if a write to dev5 actually does succeed, it seems > to work for the duration of the program; in other words, it either > crashes the first time write is called, or it never fails. > > I think the problem is in the following snippet of code, where I've > added two printk's to illustrate my theory. > > printk("qspi_write: Sleeping\n"); /* RSG */ > #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0) > save_flags(flag); cli(); > #else > local_irq_save(flag); > #endif > > QDLYR |= QDLYR_SPE; > sleep_on(&wqueue); > #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0) > restore_flags(flag); > #else > local_irq_restore(flag); > #endif > printk("qspi_write: Waking up\n"); /* RSG */ > > Sure enough, the first printk gets executed, but the second never > seems to get hit. So I'm guessing it's stuck waiting for an interrupt > that is lost somehow. > > Anyone have any ideas or similar experiences? > > Thanks, > -Bob > > > _______________________________________________ > uClinux-dev mailing list > [email protected] > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by [email protected] > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
