uClinux for the Blackfin Processor

Home » Projects » uClinux for the Blackfin Processor » Tracker » Bugs » Edit Tracker Item

[#2892] SPI DMA incomplete transmission

Submitted By: Chuck Cox
Open Date 2007-03-05 13:33:41	Close Date 2007-06-22 01:54:47
Priority: Medium	Assignee: Bryan Wu
Fixed In Release: N/A	Status: Closed
Found In Release: 2006R2-RC2	Release:
Category: Drivers	Board: STAMP
Processor: BF537	Silicon Revision:
Is this bug repeatable?: Yes	Resolution: Fixed
Uboot version or rev.:	Toolchain version or rev.: SVN or R06R2
App binary format: N/A
Summary: SPI DMA incomplete transmission
Details: We are using the SPI port in master mode with 16-bit words and DMA. I changed the .ctl_reg value in spi_adc_chip_info in stamp.c to 0x1e00 to configure it with CPOL=1, CPHA=1, LSB first. Everything else is in the default configuration. When sending packets of 8 bytes (4 words) everything works fine. When sending packets of 20 bytes (10 words) or more, it sometimes drops the last word. The write() function return value indicates all the bytes were sent, but the logic analyzer shows that it sometimes drops the last word. This error seems to happen about 1 out of 10 times. I haven't tested packets between 8 and 20 bytes, those just happen to be the sizes of the packets I'm using. If I disable DMA, the problem goes away. Since the driver only uses DMA for 12+ byte packets, it appears there is a bug in the DMA transmission handling, possibly in the DMA completion interrupt handler. This problem exists using using the SVN sources & toolchain or the R06R2 sources & toolchain.
Details: We are using the SPI port in master mode with 16-bit words and DMA. I changed the .ctl_reg value in spi_adc_chip_info in stamp.c to 0x1e00 to configure it with CPOL=1, CPHA=1, LSB first. Everything else is in the default configuration. When sending packets of 8 bytes (4 words) everything works fine. When sending packets of 20 bytes (10 words) or more, it sometimes drops the last word. The write() function return value indicates all the bytes were sent, but the logic analyzer shows that it sometimes drops the last word. This error seems to happen about 1 out of 10 times. I haven't tested packets between 8 and 20 bytes, those just happen to be the sizes of the packets I'm using. If I disable DMA, the problem goes away. Since the driver only uses DMA for 12+ byte packets, it appears there is a bug in the DMA transmission handling, possibly in the DMA completion interrupt handler. This problem exists using using the SVN sources & toolchain or the R06R2 sources & toolchain.

Follow-ups
--- Sonic Zhang 2007-03-15 04:45:57 do you have any test example code that we can replicate on our side?
--- Chuck Cox 2007-03-15 10:48:20 The current code requires external hardware to work. I'll put together a standalone test program in the next day or two.
--- Bryan Wu 2007-04-10 04:14:41 Hi Chuck: Is there any update information about this bug? I will do some testing and debugging about this. Could you please give us some hints? Thanks -Bryan
--- Hans Eklund 2007-04-10 10:53:13 Before digging too deep check my old forum post about a SPI DMA read bug. And check the HW ref. in the link i talk about in the last post in this forum thread http://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?action=ForumBrowse&forum_id=39&thread_id=1393&_forum_action=ForumMessageBrowse Im not sure this is the same sympthoms as Chuck describes, But the dropped bytes may be related to a fix to this hardware related problem(not bug, since it is specified in manual). The additional bytes read by DMA controller could screw up communications with a slave, therefore shorter transfers should be done via PIO mode. DMA reads should only take place when there is no problem for the slave if a few extra bytes of SCK cycles occurs, this is of course application dependent. I would gladly like to see a solution to this. Good luck. regards Hans.
--- Chuck Cox 2007-04-10 12:38:24 > Is there any update information about this bug? No. The SVN toolchain no longer builds here, so this problem is on the back burner until I can resolve that problem. > Could you please give us some hints? I suspect there is a bug in the code that determines when a DMA transmission is complete which occasionally causes the transmitter to be disabled before it has finished sending the data. We ran into a similar problem on the SHARC because the procedure documented in the HRM is incomplete. Perhaps there is an analogous flaw in the Blackfin documentation. FWIW, here is the code we use on the SHARC to determine if a DMA SPI transmission is complete: // Wait for DMA count to get to 0 (NOT in HRM) while (pCSPI) ; // Wait for the DMA FIFO to empty while (pSPIDMAC & (SPIS0 \| SPIS1)) ; // Wait for transmit buffer to empty while (pSPISTAT & TXS) ; // Wait for transaction to complete while (!(pSPISTAT & SPIF)) ;
--- Bryan Wu 2007-04-11 03:07:29 Hi Chunk: How do you think of Hans's comments? Do it make sense? Bryan
--- Bryan Wu 2007-04-12 06:03:23 Hi Chunk: Can you tell us some infomation about your hardware and software setting? Bryan
--- Chuck Cox 2007-04-19 17:08:23 > How do you think of Hans's comments? His problem is receiving too many characters. My problem is transmitting too few. I haven't seen a problem receiving too many characters. > Do it make sense? Yes, but it doesn't seem relevant other than the fact that they are both apparently due to problems terminating an SPI DMA transfer.
--- Chuck Cox 2007-04-19 17:12:22 > Can you tell us some infomation about your hardware and software setting? The SPI port is in master mode with 16-bit words and DMA. CPOL=1, CPHA=1, LSB first. Everything else is in the default configuration. Hardware is BF537 as master, SHARC as slave.
--- Bryan Wu 2007-04-20 03:13:20 Thanks Chunk，I will try to dig into this bug.
--- Manolo van Ee 2007-05-29 10:33:37 Hi, I found the solution for this bug, but I'm new to this open source stuff and don't know exactly how to proceed. What should I do? Manolo
--- Bryan Wu 2007-06-05 01:52:13 Hi Manolo, You can submit a patch for the code just by adding files in this bug tracker. Or just post a message including your idea in this thread. I will test it. And John DeHority submitted a solution similar with this problem: https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=3205 Thanks -Bryan
--- Manolo van Ee 2007-06-05 06:45:44 Hi Bryan, I'm either not able to add a file, or I just don't know how to do it. Anyway, John Dehority's solution is the same as mine. Alltough my code is a bit shorter: In dma_irq_handler() replace: while (bfin_read_SPI_STAT() & TXS) ; while (bfin_read_SPI_STAT() & TXS) ; With: while (bfin_read_SPI_STAT() & TXS \|\| bfin_read_SPI_STAT() & TXS) ; In addition to that I added the following to the top of the function: while (get_dma_curr_irqstat(CH_SPI) & DMA_RUN) ; Don't know if it's necessary, but then it exactly follows the example in the hardware reference manual. Regards, Manolo
--- Bryan Wu 2007-06-06 22:31:15 Thanks Manolo: After digging into the HRM and example code, I think you and John are right. There is a bug in the dma_irq_handler() as you and John pointed out. But now, I am trying to duplicate the bug. Could you please send your test case C code or some information about the Hardware setting? After verify the solution, I will apply your patch or John's idea to our SVN trunk and upstream mainline kernel. Thanks -Bryan
--- Bryan Wu 2007-06-07 01:26:31 Hi Chuck and Manolo, I replicated Chuck's bug on my side. After apply Manolo's patch, it was fixed. I commited it to kernel svn trunk and 2007R1. The patch was attached in this tracker's "Files" option tab on the top of this message thread. Could you please test it on your side, Chuck? -Bryan
--- Bryan Wu 2007-06-22 02:57:34 It should be fixed. Close it.

File Name	File Type	File Size	Posted By
spi.patch	text/x-patch	1054	Bryan Wu

Change Date	User Id	Field Name	Old Value	New Value
2007-06-22 02:57:34	Bryan Wu	status	Open	Closed
2007-06-22 02:57:34	Bryan Wu	close_date		2007-06-22 01:54:47
2007-04-06 03:01:36	Sonic Zhang	assignee	Nobody	Removed

File	Date	Previous Version	New Version	Message Log	By
No Commits Found

Dependent On Other Items

ID	Summary	Delete
No Dependencies Were Found

Items Dependent On This Item

ID	Summary
No Dependencies Were Found

Duplicate of items

ID	Summary	Delete
No Duplicates Were Found

Items that are duplicates of this item

ID	Summary
No Duplicates Were Found

Associated Item	Comment
No Associated Items Found
~~Add Association~~

Save changes Back