2008-12-05 05:26:17 Missing some PPI interrupts
Jean-Francois Argentino (FRANCE)
Message: 66401
Hello,
I play with the bfin_ppi driver I've modified (uClinux and toolchain 2008r1.5-RC3) on a CM-BF537E for a while with these parameters:
I read 4080 16 bits words at 23MHz every 2ms, 2 external frames syncs, then i diffuse it on ETHERNET.
My problem is that sometimes I'm missing 5 consecutive transfers. The error rate is quite low, something like 100x5 transfers missing for 20e9 transfers OK, but a 0 rate would be better!
I've read the PPI wiki of this site and apply all the recomandation like Enabling the DMA priority over core for external access, and allocating my buffer in the L1 cache (this trick greatly reduce the error rate)...
I try many things like reducing the PPICLK to 5MHz, disabling the BFIN_INS_LOWOVERHEAD config in the kernel config, the preemptive kernel with or without preemptible RCU, increasing the system clock at its max, without success, my error rate is still the same...
I'm fearing that I'm missing some transfer due to some linux kernel interrupts like ticks, so a 100% error free won't be possible with linux, but I hope I'm missing a configuration hidden somewhere in the kernel configuration which will magically solve my problem...
Does anybody can confirm my fear, or better point me how to solve this issue?
Regards
bfin_send.c
bfin_ppi.c
bfin_ppi.h
config-linux
TranslateQuoteReplyEditDelete
2008-12-05 05:33:10 Re: Missing some PPI interrupts
Michael Hennerich (GERMANY)
Message: 66402
Can you explain this a bit more.
What are you missing - some 16-bit words or some entire dma shots (work loads) ?
-Michael
QuoteReplyEditDelete
2008-12-05 06:05:42 Re: Missing some PPI interrupts
Ian Jeffray (UNITED KINGDOM)
Message: 66403
I believe your summary is correct Jean-Francois. It's not possible to guarantee error-free PPI in Linux. It affects a product I am developing quite badly too (high speed megapixel camera image aquisition). I've spent some considerable time trying to solve this, too.
It sounds like you've tried all the obvious suggestions on the Wiki already:
http://docs.blackfin.uclinux.org/doku.php?id=ppi&s[]=ppi
QuoteReplyEditDelete
2008-12-05 08:30:51 Re: Missing some PPI interrupts
Jean-Francois Argentino (FRANCE)
Message: 66408
To all: thanks for replying
What I found really disturbing is that it's ALWAYS 5 contiguous buffers I'm missing, not less and not more. But the missing rate is quite erratic, it can be OK for million of buffers and missing 2x5 buffers in 200000 transfers.
To Michael:
It's quite strange because the PPI status register shows 4 FIFO overflow error each time I miss 5 buffer transfers, but I'm really missing 5 buffers. I'm (quite) sure because, for the tests I fill an external 128kx16 bits wide fifo with data from 0x0000 for 0x0fff continuously at 2MHz, the FIFO rise FSYNC as soon as there's 4080 new words into it, then the bfin just MULTICAST it on my network. On a computer, I'm timestamping every datagram it receives and compare its first value, it must be the last value more 1 (modulo 0x1000), then record the last value for the next comparison. When I don't miss any PPI buffer, the difference between each timestamp is 2ms, but when I have a timestamp difference of 12ms, I always find that (last_value + 5x4080) modulo 0x1000 + 1 is the first value I receive... And i'm sure that it's not due to a network problem since all by datagrams are numbered and if a datagram is missing I don't verify the content...
To Ian:
Yes I have, but thanks to point it. Could you please tell me what performance do you reach, period of PPI FSYNC rising, number of word readed per FSYNC, PPICLK frequency and your error rate?
TranslateQuoteReplyEditDelete
2008-12-05 08:58:10 Re: Missing some PPI interrupts
Ian Jeffray (UNITED KINGDOM)
Message: 66410
I'm using 16bit transfers, of 11.5MBytes for each Fsync. Anything above 20Mhz PPICLK starts causing problems, and above about 40Mhz I never get any successful transfers. This has been repeated on custom BF527 board and BF537 EZKIT. For now, I'm using 27Mhz PPICLK and simply repeating the transfer if I detect an error. The error rate is about 1 in 50 transfers with this configuration. Noticably worse if ethernet is doing any transfer.
QuoteReplyEditDelete
2008-12-08 03:50:03 Re: Missing some PPI interrupts
Jean-Francois Argentino (FRANCE)
Message: 66493
OK thanks,
So i'll try a different way, use a GPIO to wake up the bfin and internal frame sync generation, thus if the DSP won't see the interrupt, nothing will append on PPI.
TranslateQuoteReplyEditDelete
2008-12-08 05:57:54 Re: Missing some PPI interrupts
Michael Hennerich (GERMANY)
Message: 66499
Jean-Francois,
I looked at your code.
In the PPI ERROR ISR - stop DMA and PPI immediately and let read() return an error.
u16 status = bfin_read_PPI_STATUS();
bfin_write_PPI_STATUS(0xFFFF);
if (status) {
bfin_write_PPI_CONTROL(bfin_read_PPI_CONTROL() & ~PORT_EN);
disable_dma(CH_PPI);
clear_dma_irqstat(CH_PPI);
}
The next time your application starts a read() re-arm DMA and start the PPI.
I'm pretty sure that then you won't loose 5 buffers in row.
Your PPI clock is pretty slow (2MHz ?) - So I'm sure your problem is different form Ian's.
Please check the electrical interface.
You need to keep in mind that the PPI is electrically a very fast peripheral.
The PPI may see additional edges on the PPI CLK Input in case the edge is none monotonic. Over and undershoot, reflections due to a poor HW design.
Spikes in the range of picoseconds due to ESD, or supply noise.
I've had CMOS camera sensors running for weeks at 24MHz PPI CLK (8-bit mode with packing, this corresponds to 12MHz in 16-bit PPI mode) streaming over the network - without seeing a single PPI Error interrupt.
-Michael