Quantcast
Channel: Processors forum - Recent Threads
Viewing all articles
Browse latest Browse all 17527

RTOS/OMAPL138B-EP: UART2 of the OMAP-L138: lost characters on receiver channel in interrupt EDMA-mode or in interrupt only mode

$
0
0

Part Number:OMAPL138B-EP

Tool/software:TI-RTOS

Hello at all!

 

I have a project at the C674xDSP of an OMAP-L138 SOC. This project uses the on chip UART2 of the OMAP-L138 SOC. There is some trouble around lost characters on the receiver channel in interrupt EDMA-mode or in interrupt only mode both.

 

At the SOC's GPP is running QNX, but the GPP doesn't touch the UART2.

The DSP project is using the packages below:

  DSPBIOS 5.41.03.17

  PSP drivers 01.30.01

  OMAP-L138 DSP package 1.00.00.08

  EDMA3lld package 01.11.00.03

The UART is running with 115200 Baud or (in most cases) with 230400 Baud. The streams of data to transmit and to receive are continuously with only sometime small gaps (< 1 msec) between the characters. The most time there is no any gap between the characters. But only seldom there are longer gaps (> 100 msec). To reduce the CPU load the characters are read in blocks of 64 characters instead of reading "character by character". To guarantee that ALL received characters are processed immediately (within 2 msec) the data are read from the

Rx mini driver with a timeout of 1 msec.

 

In the seldom cases of longer gaps (> 100 msec) there are received less characters than the buffer's size allows and the timeout happens. I've not yet found a way to get the information how many characters were received before the timeout aborted the GIO_submit() / GIO_read() call. If the GIO_submit() / GIO_read() call returns IOM_COMPLETED the function received the number of characters according to the given limit. In this case the length-parameter of the GIO_submit() / GIO_read() function is set to the given max number of characters and everything works fine. But in the case of the GIO_submit() / GIO_read() function returns IOM_ETIMEOUT or IOM_ETIMEOUTUNREC the length-parameter

is set to zero always by the DSP-BIOS's GIO_submit() function - altough there are received some characters (less than the length-parameter allowed) and altough these characters are stored in the buffer.

The return value IOM_ETIMEOUTUNREC is caused by the DSP-BIOS's GIO_submit() function. In the case when the GIO_submit() function's call to GIO->SEMPEND() function timed out the GIO_submit() function sets the length-parameter to zero always. After that the GIO_submit() function calls the mini driver's mdControlChan function uartMdControlChan() with the command ID IOM_CHAN_TIMEDOUT. Here is a problem of the PSP's UART mini driver because this mini driver doesn't know this command ID. So the mini driver's uartMdControlChan() function returns IOM_ENOTIMPL. This results in the DSP-BIOS's GIO_submit() function is returning IOM_ETIMEOUTUNREC... It's not fine but I can deal with with this behavior. Another thing is that the DMA and the UART keep still active and there is not performed any operation to stop the ongoing IO. My application layer's work around in the IOM_ETIMEOUTUNREC case is to call GIO_control() with the command ID Uart_IOCTL_CANCEL_CURRENT.

However, my problem in any case is that I have to process ALL received characters - also in the case of timeout. Altough there are received characters in the buffer the legth/parametr is set to zero.

The way to limit the receive buffer size to one character only is bad since the baud rate is up to 230400 and so the CPU load would be increased. So I prefer the DMA interrupt mode of the UART driver or at least the interrupt mode with active FIFO. But how to get an information how many bytes ther are received before the timeout occured?

I've just tried to modify the UART driver's source code. So I've add the command ID IOM_CHAN_TIMEDOUT to the driver's function uartMdControlChan(). If this command ID is parsed I stop the current IO by running a sequence according to that one if the buffer full event occured. Here I have the access to the number of characters received before, but from the mini driver's point of view there is no way to give this information up to the DSP_BIOS's GIO_submit() function neither nor up to the application layer. Of course, the best way would be to keep the UART driver "as is" and to get the number of received characters to the application via another way...

 

Hope someone can help me,

Best regards,

Uwe

 


Viewing all articles
Browse latest Browse all 17527

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>