AM3352: UART receive data loss

Hi Kanae,

TI Processor SDK v4 has multiple releases, which one do you use?

Does your kernel use 8250_omap driver, not omap_serial?

If you use 8250_omap, does the issue still happen if disable DMA for 8250_omap driver?

In kernel manuconfig:

Device Drivers >
    Character devices >
        Serial drivers >
            8250/16550 and compatible serial support >
                DMA support for 16550 compatible UART controllers

Hi Liu,

Thank you for your reply.

I have checked the driver information to my customer that uses " 8250_omap driver".
When it sets disable DMA support, but it still occurs the error.

Here are the additional information from my customer.

*****************************************************************************************

Occurrence frequency: in about 2000 trials

Error state 1: about 1,200 times

Error state 2: about 40 times.

Environment :

AM3352 custom board

Customized Linux OS

When it is checked using TI AM335xEVM just 50 trials, there is no error.

When they changed to the wait time of the process of reading data from FIFO,

there is no error at all.

*****************************************************************************************

Question:

My customer do not know the cause, so they cannot judge whether it is a appropriate measure, or not.

Could you please tell me the cause and the appropriate measure?

From your experience, If you have the detailed information such as how much should it be added the wait,

it really would be appreciated.

Best regards,

Kanae

Kanae,

Kanae said:

Occurrence frequency: in about 2000 trials

What occurs in about 2000 trials?

Kanae said:

Customized Linux OS

What version of the Processor SDK kernel is the customized Linux based on? What the customization is? Is the kernel modified?

Kanae said:

When it is checked using TI AM335xEVM just 50 trials, there is no error.

Is the 50-trails test long enough? Can you please test it longer? What kernel do you use when testing on the TI EVM?

Which uart port is used in your custom board? and which port you tested on the TI AM335x EVM?

Kanae said:

Could you please tell me the cause and the appropriate measure?

From your experience, If you have the detailed information such as how much should it be added the wait,

I still need more information to understand the issue. Please answer my questions above.

Hi Liu,

Thank you very much for your support.

Regarding Occurrence frequency, I change to the expression as following.

Occurrence frequency:
-Error state 1*: about 1,200 times occurrence in about 2000 test trials
                 (about 60%)
*Error state1: Received processing ends with 50 bytes.　When checking the data, 0x41 is missing. (50th byte)

-Error state 2**: about 40 times occurrence in about 2000 test trials       
                 (about 2%)
**Error state2: It receives 51 bytes, but 0x41 is missing.　And a data not transmitted from PC is included in 51st byte.

I have asked some of your questions to my customer.
I will have the information you asked, and report them to you later.

Best regards,
Kanae

Hi Liu,

I have got customer's answers as follows.

-What version of the Processor SDK kernel is the customized Linux based on?

A1. Using SDKv4.3 and kernel version 4.9.69

-What the customization is? Is the kernel modified?

A2. On custom board, RS485 is mounted and it is modified to control GPIO at switching the RTS

   by driver in order to control transmission / reception with GPIO.

-Is the 50-trails test long enough? Can you please test it longer?

-What kernel do you use when testing on the TI EVM?

A3. They did the additional test with AM335x　StarterKit at 2000 times and there is no error.

-Which uart port is used in your custom board? and which port you tested on the TI AM335x EVM?

A4. Starter kit: UART5

  　 Custom board: UART5

Result of their investigation;

- They have found that this error status seems to be caused by clearing the RX FIFO at an unintended timing.

- Their board uses half-duplex RS485 and it seems to clear the FIFO at the transmission stop processing

　if the driver is set the half-duplex RS485.

Current measures;

- If the interruption processing is a reception related interrupt, the transmission related processing is not executed.

- When it is operating with RS485, it does not call the flush processing called from serial_core.c.

They are planning to deal with it in above measures.

Is there any notes for the software during operating with half-duplex RS485?

Best regards,

Kanae

Hi Liu,

I was wrong the TI EVM name that my customer use.
They use TMDXEVM3358, not AM3358_StarterKit.
Sorry for making you confused.

>Why and how your customer uses GPIO to control the RTS?

In the status of UART driver initialization, RTS becomes HI,
but their board is "HI = transmission mode", so they decided to control with GPIO
so that it will not be in unintended transmission mode.

>It does sound like sw timing issue which causes RX FIFO flush too soon.

→ The RX FIFO flush is performed by the original driver,
but is it possible to fix the software to delay this?

Although they are considering to avoid calling the flushing process
as described "Current measures" in last my post,
is there any possibility that other problems may occur by avoiding calling flush?

Best regards,
Kanae

Kanae,

I am trying to understand why CTS is high after init, or if possible to change in sw. Please give me some time to look at this.

Meanwhile, can you please ask your customer if they did apple-to-apple comparison on their board and AM335x EVM, for example, GPIO controlling RTS, and RS-485 transfer? Because I am not sure how their test was done on the AM335x EVM, which doesn't have UART5 enabled by default, and doesn't have RS-485 on the EVM.

Hi Bin Liu,

I am sorry my reply is late.

Here is how their test was done on the AM335x EVM.

UART5 was enabled by the following procedure.
・ Replace with DTB which is enabled UART5.
・ Operate DipSw for CPLD and select Profile #6

The RS485 transceiver is not connected, but my customer judged that it is no problem
even if checking with EVM's "RS232".
Because the problem transmission data missing is no data transmission from the AM 3352.

Regarding the solution, they have just kept their own measure posted on Oct-1st.

Best regards,
Kanae