• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 1713 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BIOS UART flush the read buffer

AlanZhang
Intellectual 515 points

Hi,

I am using PSP 1.10.03 UART driver to communication with Linux. My settings for UART is PSP_OPMODE_DMAINTERRUPT and synchronous communication.  No change has done to UART driver at all.

Here is my communication protocol: first I read the header from UART0, and then find out how many bytes I need to read in the following.

Problem: when I find out the wrong header, I need to discard any remaining data in the read buffer so that it will be ready for next communication.  I used following two statements to flush:

1.    GIO_flush(Uart_fd);   // This one don't flush the remaining data at all.

2.    GIO_control(Uart_fd, PSP_UART_IOCTL_RESET_RX_FIFO, NULL);

// This one does flush the remaining received data. However, in next communication, somehow the first character of previous communication is always present before next data. I don't know why and where to change?

Can you help?

Thanks.

Alan

  • 0
    TI__Expert 5500 points

    Hi Alan,

     

    Since it is a synchronous communication, you have to first reset the FIFO and then, cancel the current IO. This is because, in DMA mode once the PaRAM sets are programmed the DMA transfers the programmed amount of data completely. So it is necessary to just cancel the current IO but not all the IO. 

                status = GIO_control(Uart_fd, PSP_UART_IOCTL_RESET_RX_FIFO, NULL);
                status = GIO_control(    Uart_fd, PSP_UART_IOCTL_CANCEL_CURRENT_IO, NULL);

    Please try this and let us know the results..

    Assuming data is continuously pumped into the RX FIFO,  after resetting the FIFO the RX FIFO will be again filled with data in no time!. And this data will be read in the next transaction.

    Alan said:
    This one does flush the remaining received data. However, in next communication, somehow the first character of previous communication is always present before next data

    I am some how, a little confused by the above statement.. Provided you are resetting the FIFO, it is not possible to see the  first character of previous communication before next data is my understanding. Is it the first character of previous communication before next header? Or last character of previous communication. Can you please clear/confirm us on this? elaborate? 

     

    Thanks & regards,

    Raghavendra

  • 0 in reply to Raghavendra Maddikery
    Intellectual 515 points

    Yes, it works perfectly!

    "first reset the FIFO and then, cancel the current IO" is the magic trick.  Thanks.

     

    As for the repeated first character problem, I am confused too. But it is exactly what happened.

    If I reset the FIFO only, not cancel the current IO, the first character of receiving buffer always repeats the first character of last communication, followed by the new data transferred. (Note: the new data did not lose any character.) For example:

    1. RxCM005:help;    => DSP received buf: "RxCM005:help;".  Since it is wrong format, so DSP reset FIFO, but not cancel the current IO.

    2. TUCM007:time;   => DSP received buf: "RTUCM007:time;"

    3. MYTX008:help;   => DSP received buf: "TMYTX008:help;"

    ...

     

    Since the problem is already resolved, if you don't have time and resource, you can ignore this problem for now.  Thank you very much for your support.