2009-04-08 05:08:30 PPI fails intermittently on BF537 STAMP
Michael Worcester (UNITED KINGDOM)
Message: 72392
Hi,
All of this is on a BF537 STAMP board connected to a MT9M CMOS camera module.
I am trying to get image capture working via the PPI with some success;
using the bfin_ppifcd driver from the 2008R1.5-RC3 uClinux release and a
modified version of the ppifcd_test program. The test program has been
modified to use i2c to trigger the camera and not attempt to use GPIO at
all, as this caused errors.
The capture works pretty well most of the time, however sometimes it hangs
in the driver ppi_read function, after calling:
wait_event_interruptible(*(pdev->rx_avail), pdev->done);
When the driver hangs, the irq handler is never called, leading me to believe
that some or all line syncs/pixels/frame syncs are getting lost somehow.
If I enable DI_SEL in the dma config (which according the blackfin docs for the
PPI should make the dma interrupt after every line), the irq handler does seem
to get called sometimes, which leads me to believe the frame sync is not being
missed, rather it is one or more line syncs that are getting lost. This hypothesis
is further supported by the fact that when I decrease the vertical resolution of
the capture it fails far less often (from 1/5 to 1/100 going from 1024 -> 800).
Furthermore, even when the capture is working, occasionally there are artifacts
on the image where it looks like blanking of a line is getting captured and the
rest of the line is offset to the right by a hundred pixels or so.
This could all be signal quality issues, given the problems seem to arise at
random, however if anyone else has any thoughts on the matter I would very
much appreciate any help I can get.
Thanks,
Michael.
QuoteReplyEditDelete
2009-04-08 07:45:27 Re: PPI fails intermittently on BF537 STAMP
Jean-Francois Argentino (FRANCE)
Message: 72417
Hello,
It sounds like the problem I'm facing, see this thread:
from message id 72260...
But, well, I don't have any solution by now...
TranslateQuoteReplyEditDelete
2009-04-08 08:17:03 Re: PPI fails intermittently on BF537 STAMP
Michael Worcester (UNITED KINGDOM)
Message: 72418
Interestingly enough my board has a silicon revision 0.2 BF537, which is locking up. I understand that you are only facing this problem with the 0.3 chips and the 0.2 chips work fine for you?
I have access to a 0.3 chip and will test on there and get back to you!
Thanks for the quick reply,
Michael.
QuoteReplyEditDelete
2009-04-08 11:11:26 Re: PPI fails intermittently on BF537 STAMP
Jean-Francois Argentino (FRANCE)
Message: 72422
Not exactly, the two rev0.2 DSP where I don't have the problem are quite old (two years or more), but one that a co-worker lent to me is more recent and present the same symptom...
And more disturbing, 3 DSP rev0.3 works fine for 7 which doesn't...
TranslateQuoteReplyEditDelete
2009-04-09 09:20:04 Re: PPI fails intermittently on BF537 STAMP
Jean-Francois Argentino (FRANCE)
Message: 72464
I'm thinking about a dirty workaround that could work:
in the reading function, replacing the "wait_event_interruptible" function by a "wait_event_interruptible_timeout" calling. If it returns due to the timeout expiration, test the current x count, if it's null, running as usual...
That's dirty, I don't like that, but it could work while we don't understand why the DMA end of transfer doesn't wake up the IRQ handler...
TranslateQuoteReplyEditDelete
2009-04-23 06:44:03 Re: PPI fails intermittently on BF537 STAMP
Michael Worcester (UNITED KINGDOM)
Message: 73095
The wait_event_interruptible_timeout worked great!
It seems like a dirty "hack" but isn't really as all the issues I have been having are signal integrity related, so a better cable with proper termination helped but it's still nice to have the timeout there just in case a glitch _does_ occur it doesn't freeze the entire frame capturing sequence.
Thanks,
Michael.
QuoteReplyEditDelete
2009-04-27 09:56:23 Re: PPI fails intermittently on BF537 STAMP
Jean-Francois Argentino (FRANCE)
Message: 73289
Glad to read that it works for you... Because for me, when this problem occurs, I can see that the DMA transfer never start (I was thinking that it never rise the interrupt at its end). In fact, for my validation process, I have a counter that feed the PPI, and when the problem occurs, I still found old value in my buffer... Do you have any way to verify the data you have in your buffer, I mean, if data comes from a camera sensor, it could be hard to know if the image is an old one...