AM3715: UART2 receive problem

Hi Holger,

Which Linux kernel or SDK version is it?

Which UART is used for the Linux debug console?

Hi everybody,

The Kernel Version is:

Linux gen3cpu 4.14.32-rt25-gf29f0b9709 #9 SMP PREEMPT RT Mon Aug 5 07:10:28 UTC 2019 armv7l GNU/Linux

We use uart 1 for RS232

uart 2 for RS485

and uart 3 for debug

We use this uart 2 pin mux configuration: 

OMAP3_CORE1_IOPAD(0x21AC, PIN_INPUT | MUX_MODE5)     // HSUSB0_DATA1.uart2_rx
OMAP3_CORE1_IOPAD(0x21AA, PIN_OUTPUT | MUX_MODE5) // HSUSB0_DATA0.uart2_tx
OMAP3_CORE1_IOPAD(0x21B0, PIN_INPUT | MUX_MODE5)      // HSUSB0_DATA3.uart2_cts
OMAP3_CORE1_IOPAD(0x21AE, PIN_OUTPUT | MUX_MODE5) // HSUSB0_DATA1.uart2_rts

Greetings

Benedikt

Hi,

I tried WinCe and Linux on the same Board, but with no successfully Rx communication on Uart 2. 

If I use the same Pin as GPIO the input / output will work.

To check the RS485 transceiver I redirected the connection to UART 2 RX / TX to UART 3 RX/TX.

So by disconnecting and reconnecting the lines. Now I can communicate via the hardware without any problems.

But why is it not working with UART 2?

Greetings

Benedikt

Hi Benedikt,

Benedikt Cyranka1 said:

To check the RS485 transceiver I redirected the connection to UART 2 RX / TX to UART 3 RX/TX.

So by disconnecting and reconnecting the lines. Now I can communicate via the hardware without any problems.

Do you mean if you modify the board to move the RS485 transceiver from UART2 to UART3, you can receive data on UART3 with the transceiver?

With the transceiver connected to UART2, can you please probe the UART2 RX pin to see if you can see the RX data between AM3715 and the transceiver?

Yes if I redirect the date from uart2 to uart3 via some cables it work. For this step I need to modify the hardware.

To check if the uart2 get the messages I took a osci and measure on the data lanes from the incomming port until to the last chance to measure on the board next to the cpu. And the data will receive the cpu pin.

The last thing to check was if the cpu pin connected to the baseboard. For this I change the pin mux configuration for the RX and TX pin and use this as gpio. This works without any problems. 

Benedikt,

Here is another test.

Can you try to bypass the transceiver and directly connect UART2 and UART3 (UART2 RX to UART3 TX, UART2 TX to UART3 RX), then check if you can transmit and receive data between UART2 and UAT3?

I tried to bridge uart2 rx with uart2 tx to be able to send and receive here.

I set the port so that sending and receiving is possible.

On the baseboard I could measure that the message was sent, but at the linux nothing was interpreted. The receiving registers did not receive anything. 

we use the following CPU:

ARM Cortex-A8, 1GHz, -40..90°C TJ, 423-FCBGA, TI: AM3715CUSD100, RoHS-konform

On WinCE it was the same behaviour as on linux. 

So you directly loop back UART2 RX and TX but was unable to receive on RX?

What application do you use for the UART test?

I typically use https://github.com/cbrake/linux-serial-test.git

Yes I simple redirect Uart2 tx to Uart2 rx.

Then I write with echo 1 > /dev/"mytty"

Next I checked how many charakters was sended and received with  cat /proc/tty/driver/serial

Like this example from an other maschine: 

0: uart:MSM mmio:0x078B0000 irq:10 tx:8950 rx:157 RTS|CTS|DTR|DSR|CD
1: uart:MSM mmio:0x078AF000 irq:9 tx:0 rx:0 CTS|DSR|CD

If I send via TX the tx count rise.

Because of the bridge the RX count need to rise also, but it was always NULL.

Okay maybe the test is not valid but if I measure with an ozci directly on the data line I see that the UART2 RX is supplied with data.

No matter if I use the Uart2 TX, Uart3 or an external source like my PC. But the processor doesn't evaluate anything.

Especially on Uart1 and Uart3 I can read and write the data. And both use the same driver as Uart2.

Do you have any other ideas besides more tests? 

how did you actually test that the UART2 Rx works on this pin configuration at all?

On the Evalboard these pins are not connectable.

This is our pin configurarion for the UART2:

OMAP3_CORE1_IOPAD(0x21AC, PIN_INPUT | MUX_MODE5)     // HSUSB0_DATA1.uart2_rx
OMAP3_CORE1_IOPAD(0x21AA, PIN_OUTPUT | MUX_MODE5) // HSUSB0_DATA0.uart2_tx
OMAP3_CORE1_IOPAD(0x21B0, PIN_INPUT | MUX_MODE5)      // HSUSB0_DATA3.uart2_cts
OMAP3_CORE1_IOPAD(0x21AE, PIN_OUTPUT | MUX_MODE5) // HSUSB0_DATA1.uart2_rts

Benedikt,

I didn't test this UART2 on AM3715 specifically. Because AM3715 was release long time ago, I don't even have its evm. I checked the device Errata but there is no device issue related to UART2, so I can only try my best to help you based on the information you provided.

Do you know a project that use the Uart2? 

Maybe I am the first how use uart2 with these pins and this is an hardware issure.

Greetings

Benedikt

Benedikt,

I personally don't know much of any AM3715 project, but AM3715 has been released many many years ago and ton of projects used it, so I highly doubt you are the only one uses UART2.

But to debug your problem, you first have to ensure you test procedure is correct, the test program has to ensure both ends of the UART connection agree on the termios settings, then you can check the UART registers to understand the UART controller behavior, but not rely on the kernel tty layer procfs entries, which is a purly software. As I mentioned above, it is better first bypass the RS485 transceiver to only focus on the UART2 interface. Good lock.