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.

OMAPL138 PRU UART Driver issue

Other Parts Discussed in Thread: OMAPL138

Hi,

We are currently working on OMAPL138 based product. We need two UARTs, for these we are using PRU UART. We have configured PRU as follows:
==========================================================================
#define NR_SUART    2
#define SUART_FIFO_LEN           15
#define  PRU_ACTIVE     SINGLE_PRU
#define SUART_DEFAULT_OVRSMPL   SUART_8X_OVRSMPL
#define SUART_DEFAULT_BAUD      230400

#define PRU_SUART1_CONFIG_DUPLEX (PRU_SUART_HALF_TX | PRU_SUART_HALF_RX)
#define PRU_SUART1_CONFIG_RX_SER (PRU_SUART_SERIALIZER_13)
#define PRU_SUART1_CONFIG_TX_SER (PRU_SUART_SERIALIZER_14)

#define PRU_SUART2_CONFIG_DUPLEX (PRU_SUART_HALF_TX | PRU_SUART_HALF_RX)
#define PRU_SUART2_CONFIG_RX_SER (PRU_SUART_SERIALIZER_9)
#define PRU_SUART2_CONFIG_TX_SER (PRU_SUART_SERIALIZER_10)
==========================================================================

When I insert suart_emu.ko module, I got following debug messages:

ti_omapl_pru_suart.1: ttySU0 at MMIO 0x1d00000 (irq = 3) is a suart_tty
ti_omapl_pru_suart.1: ttySU1 at MMIO 0x1d00000 (irq = 4) is a suart_tty
ti_omapl_pru_suart ti_omapl_pru_suart.1: ti_omapl_pru_suart device registered(pru_clk=186000000, asp_clk=150000000)


This PRU UART module creates two node "/dev/ttySU0" and "/dev/ttySU1". We are able to Transmit and Receive data on both UARTs.
We are able to Transmit and Receive file having 10MB size.

In our project, OMAPL138 communicating with Host PC using UART serial port. Host PC sends caommands(10 to 100 Bytes) to the OMAPL138 over serial port. OMAPL138 receives command from PRU UART, processes this commands and sends response(10 to 1000 Bytes) to Host PC using PRU UART. Now, with 15 FIFO Length, sometimes Host PC receives corrupt data. We debugged this issue and put debug messages into suart driver(omapl_pru_tx_chars function). Data are correct and these carrect data passed to the pru_softuart_write() function. On HOST PC, we have our own Utility which send/receive command/response on COM port. Same time, we run Serial Monitor tool to debug this issue. From this tool, we come to know that response sends by OMAPL138 and data received by COM port are different. So, Corrupt data are transmitted from OMAPL138 on PRU UART line.

With same setup, If we change the FIFO Length to 1 then data corruption is disappear and starts getting correct data. But when OMAPL138 is fully loaded, sometime we receive CHN_TXRX_STATUS_OVRNERR overrun error and because of overrun error, serial communication breaks.

We understand that with single FIFO, it is quite possible to get FIFO overrun error, but why it is not working with 15 FIFO length?

Please help us to resolve this issue.

Thanks and Regards,
Dilip

  • Hi Dilip,

    We recently created a fix for an issue that sounds similar to your 15 FIFO corrupt data error.  This new firmware is now available on Mistral's website:  http://www.mistralsolutions.com/pes-support/support-downloads/l13x-daughter-card-documentation-software.html#. 

    Please let me know if you still experience the corrupt data issue with this new firmware.

    Regards,

    Melissa

  • Also, I just noticed that you are configuring the SUART_DEFAULT_BAUD as 230400.  Please note that 115200 is the maximum supported baud rate.  See the release notes on Mistral's website for additional details.

    Regards,

    Melissa

  • Hi Melissa,

    I have done basic testing of this new release. So far, It looks like data corrupt issue is resolved. I will continue my testing and let you know if I find any issue.

    Thanks for your support.

    Regards,

    Dilip

  • Hi Melissa,

    We have a requirement to support 115200,57600, 38400, 19200 and 9600 baudrates. To support 38400 baudrate, we have changed SUART_DEFAULT_BAUD to 230400. So far, we haven't seen any issue with this change.

    Please let us know is there any better way to achieve 38400 baudrate.

    Thanks,

    Dilip

  • Hi Dilip,

    In general, the SUART_DEFAULT_BAUD of 230400 is not recommended because it is very limited in the number of UARTs and baud rates supported.  Please refer to the limitation section of the Quick Start Guide for additional details (http://www.mistralsolutions.com/pes-support/support-downloads/l13x-daughter-card-documentation-software.html).

    Pre-scalar 3 support will be made available in Q4.  This will then allow you to use a maximum baud rate of 115200 to achieve all required baud rates (including 38400). 

    Regards,
    Melissa