2009-09-18 16:07:25 SPORT-UART problem .. (and possible fix)
Eduardo Tagle (ARGENTINA)
Message: 80144
Well, i have developed a custom board based on the BF532 processor, and one of the requirements was to provide 2 UARTs ... The idea was to use the only native UART of the blackfin, and an emulated one, using one of the SPORTs ... But, while testing the emulated UART, i have found several problems, and some of them seem to be unfixable ones:
> When performing full duplex communications, sometimes the sport-uart seems to lose received characters. I have instrumented the sport-uart driver, and found the cause, but there is no fix. The problem seems that sometimes , RX interrupt processing latencies make the driver fail to read (miss) a received word before the next one is received. This "latency" is caused by the driver itself, and that is the problem. The driver, when transmitting a sequence of bytes, at the end always waits for the THR (transmit holding register) to become empty before shutting donw the SPORT Tx. But, this wait is performed with interrupts disabled. This wait can last longer than the time required to receive a word + overhead of call of the RX routine. The result is that a RX word is lost. I found no way to fix that problem, at least, using PIO
So , i have implemented a DMA driven approach to TX and also RX words in the sport uart. Using DMA, not only reduces CPU usage, but also cures the problem of missign words (as DMA transfers work even if interrupts are disabled)
I think this driver could be useful to many people, i attach it to the endo of this post and release under the GNU license. The driver itself is based on the original SPORT-UART driver and also on the native UART driver of the blackfin; supports PIO or DMA operation (PIO has the above posted problem, i found no solution for that, and i am open to hear if something could be done about it)
All communication formats are supported, even parity is supported ... I have tested all of them. The only thing that remains to be tested is the break code. I have no exact clue on how it should work. The code is there, but i haven-t tested it yet.
Well, hope it helps, the driver is not posted as a diff just because there are too many modifications ... I also included the KConfig options to support the new driver...
Regards, Eduardo
PS: The driver was checked against latest SVN driver in thrunk,so, unless i have missed something, all workarounds implemented for the sport-uart in thrunk are also present in this one
PS: While writing this driver, i found a (silly) bug on the Native Serial driver of the Blackfin. Please check , while reading resources used for the serial driver, there-s a typo there that wrongly assigns the cts_pin and rts_pin ...
sport-uart.zip
TranslateQuoteReplyEditDelete
2009-09-20 23:07:49 Re: SPORT-UART problem .. (and possible fix)
Sonic Zhang (CHINA)
Message: 80170
PS: While writing this driver, i found a (silly) bug on the Native Serial driver of the Blackfin. Please check , while reading resources used for the serial driver, there-s a typo there that wrongly assigns the cts_pin and rts_pin ...
---
What do you mean "wrongly assigns the cts_pin and rts_pin"?
QuoteReplyEditDelete
2009-09-20 23:44:07 Re: SPORT-UART problem .. (and possible fix)
Sonic Zhang (CHINA)
Message: 80172
OK. I see the typo error in bfin_5xx.c. Thanks.
QuoteReplyEditDelete
2009-09-21 06:48:59 Re: SPORT-UART problem .. (and possible fix)
Sonic Zhang (CHINA)
Message: 80186
> When performing full duplex communications, sometimes the sport-uart seems to lose received characters. I have instrumented the sport-uart driver, and found the cause, but there is no fix. The problem seems that sometimes , RX interrupt processing latencies make the driver fail to read (miss) a received word before the next one is received. This "latency" is caused by the driver itself, and that is the problem. The driver, when transmitting a sequence of bytes, at the end always waits for the THR (transmit holding register) to become empty before shutting donw the SPORT Tx. But, this wait is performed with interrupts disabled. This wait can last longer than the time required to receive a word + overhead of call of the RX routine. The result is that a RX word is lost. I found no way to fix that problem, at least, using PIO
---
The issue that RX interrupt may blocked too long by TX stop wait loop in PIO mode can be easily solved by following patch. This patch only waits for the last char in the TX fifo. One char delay in RX interrupt handler is acceptable since there is a 4-char RX fifo in SPORT.
Please try the SVN trunk.
Index: drivers/serial/bfin_sport_uart.c
===================================================================
--- drivers/serial/bfin_sport_uart.c (revision 7381)
+++ drivers/serial/bfin_sport_uart.c (working copy)
@@ -271,7 +271,13 @@
}
if (uart_circ_empty(xmit) || uart_tx_stopped(&up->port)) {
- sport_stop_tx(&up->port);
+ /* Waiting loop to stop SPORT uart TX from TX interrupt is
+ * too long. This may block SPORT RX interrupts and cause
+ * RX FIFO overflow. So, do stop sport TX only when the last
+ * char in TX FIFO is shifted into shift register.
+ */
+ if (SPORT_GET_STAT(up) & TXHRE)
+ sport_stop_tx(&up->port);
return;
}
QuoteReplyEditDelete
2009-09-21 17:01:30 Re: SPORT-UART problem .. (and possible fix)
Eduardo Tagle (ARGENTINA)
Message: 80205
The patch works perfectly! ' Thanks a lot... Just for reference, here is the test program i use to try serial drivers... You simply loopback TX to RX using a wire, and then run the test!
serialtest.c
TranslateQuoteReplyEditDelete
2009-09-22 00:09:14 Re: SPORT-UART problem .. (and possible fix)
Frank Van Hooft (CANADA)
Message: 80208
Hey Sonic, will you be putting your fixes into 2009R1, or only the SVN trunk? Thanks.
QuoteReplyEditDelete
2009-09-22 00:23:46 Re: SPORT-UART problem .. (and possible fix)
Sonic Zhang (CHINA)
Message: 80210
Yes. Both.