AM6412: UART dropping bytes with 3Mbps Baud rate

Hi Leon,

I am not sure how feasible to confirm this, but have you checked if the byte lost is on the AM6412 side, not the sender UART?

Hi Bin,

Actually, we just used a scope to probe the signals. the signal looks pretty good. we didn't see any bit loss in the frame that it only received 15B. Also, kernel driver was not reporting any buffer overrun. I'm wondering if it's possible that AM6412 is not sampling fast enough and skipped some bit which result a incomplete byte got dropped.

Thanks a lot,

Leon

Hi Leon,

I am looping our HW expert for comments.

Hello Leon,

Can you please confirm if you are following the below table for baudrate configuration.

Table 12-603. UART Baud Rate Settings (48-MHz, 160-MHz, 192-MHz Clock )

Can you provide additional details on the setup. Would you be able to share the schematics for a quick check?

Do you see change in behavior (errors) when you increase or decrease the speed around the 3Mbps,

Regards,

Sreenivasa

Hi Sreenivasa,

We're kind of using the reference design of SK-AM64 eval board. but add a buffer for UART to meet the requirement of maximum capacitance, as below:

This issue happens with 3Mbps baud rate. it's almost gone with 1Mbps.

We're using the default dts file which is using 48Mhz reference clock.

If detailed schematics is needed, let me check with our hardware guy to figure out a secure way to send it. 

Thank you so much,

Leon

Hello Leon, 

Thank you.

Would it be possible for you to test one speed above and one speed below the 3Mbps.

Can you provide the connection details how you are connecting the UART externally??

I need the schematics in a searchable PDF to do any quick review including the connections from the external UART interface connector to the SoC.

Regards,

Sreenivasa

Hi Sreenivasa,

We tested it with 1Mbps baud rate. The error is almost gone. I saw only 1 byte loss out of 50k frames received.

I'm working with hardware team for the schematic details.

Is there any similar uart issue on 3Mbps baud rate being noticed before?

Thanks a lot,

Leon

Hi Sreenivasa, I send you private message with the schematics. Search for CPU_HASH1_UART_TXD (TX net) and HASH1_CPU_UART_RXD (RX net) nets. We measured signal before and after the U31 buffer for the RX signal and signal looks very clean with small rise and fall times. Let me know if you need more details.

Hello Leon, 

Thank you for the inputs and understand.

My recommendation was to test 2.5M and 3.8M to verify the difference.

Is 2.5 better than 3 and 3 better than 3.5.

These results could help in analysis.

Regards,

Sreenivasa

Hello Darshan, 

Thank you for the inputs.

Let me review.

Can you please describe the setup you are using from th SoC to may be the terminal (laptop)

Can you pls remove the pullup on the TXD pin and do a check. I would suggest using a 0.1uF for C179 and C180.

Regards,

Sreenivasa

Hi Sreenivasa, This UART don't connect to terminal or laptop. From the control board (Schematics I shared), it goes to our ASIC board where UART connects directly to the ASIC UART connection.

BTW, we are seeing clean good signal at the RX of the AM6412. The issue we are seeing is some bytes are missing. Either the 1st or 2nd byte or rarely the 3rd byte. When we probe the signal, we see the byte on the scope but TI chip cannot read it correctly or loosing the byte.

Hello Darshan, 

Thank you for the inputs.

Couple of thoughts 

Would it be [possible to perform a loopback test on the SoC side of the UART interface.

The other test is to confirm if the increase in speed is causing the error or if the 3Mbps is causing error. To check this we need your help to test at 2.5 and 3.68M and compare the error.

Regards,

Sreenivasa

Hi Sreenivasa,

I did some tests with 1.5Mbps, there's a error rate about 1/5000 for our 16B frames. basically error rate increases along with baud rate.

1.0M: ~1/40000

1.5M: ~1/5000

3.0M: ~1/1000

for 2.5M & 3.68M, the test was not successful as the these baud rates have a far offset on the Am64x chip and the communication was broken.

Thanks,

Leon

correction: for 2.5Mbps, there's a far offset on AM64x chip. for 3.68M, it's not a standard rate supported by stty command so I didn't test it.

Hello Leon 

Thank you.

Have you had a chance to bypass the buffer and test any time? 

From AM6412 to the other chip, everything looks good. No packet loss is observed.

Would it be possible to loopback the AM6412 output and do a check.

Regards,

Sreenivasa

Hello Leon 

Thank you.

For the 2.5M you might have to change the source clock to 160.

Could you do a check please.

regards,

Sreenivasa

Hi Sreenivasa,

We did it before. without a buffer, we're seeing too many errors with cable length of 30cm+. Even 10cm cable would cause some errors with 1Mbps.

Thanks,

Leon

Hi Sreenivasa,

Sure, we can do a test with 2.5Mbps of ref clock 160.

meanwhile, it's clear that it get a higher error rate with high baud rate.

Thanks,

Leon

Hello Leon,

Thank you.

What is the current cable length that you are using.

I was assuming the communication was between board to board.

Regards,

Sreenivasa

Hello Leon

Thank you and understand.

The 2.5M would eliminate any of the concerns we may have with the baud rate division.

Regards,

Sreenivasa

Hi Sreenivasa,

Not sure if this is the correct change. But it seems not working as stty baud rate setting won't take effect now.

We're using main_uart1. My change is this line only:

diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi

index f7725737a236..b45a2fc0ab18 100644

--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi

+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi

@@ -242,13 +242,13 @@

        main_uart1: serial@2810000 {

                compatible = "ti,am64-uart", "ti,am654-uart";

                reg = <0x00 0x02810000 0x00 0x100>;

                reg-shift = <2>;

                reg-io-width = <4>;

                interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;

-               clock-frequency = <48000000>;

+               clock-frequency = <160000000>;

                current-speed = <115200>;

                power-domains = <&k3_pds 152 TI_SCI_PD_EXCLUSIVE>;

                clocks = <&k3_clks 152 0>;

                clock-names = "fclk";

        };

Kernel message seems good (it was showing base_baud = 3000000 with 48MHz clock):

[    3.374270] 2810000.serial: ttyS2 at MMIO 0x2810000 (irq = 19, base_baud = 10000000) is a 8250

But ttyS2's baudrate is not configurable now. we're working on SDK8.04.

Thanks a lot,

Leon

Hello Leon,

Thank you.

Let me assign to the software expert to support.

Regards,

Sreenivasa

Hi Leon,

Leon Chang said:

But ttyS2's baudrate is not configurable now. we're working on SDK8.04.

What do you mean by "not configurable"? Is the baudrate stuck at 2.5Mbps or the other configured baudrates are not correct any more?

I suspect you meant the latter. In the TRM Table 12.603, 2.5Mbps is the only baud rate which uses 160MHz source clock. Now when you modified kernel device tree to set the source clock to 160MHz, adjusting baud rate from user space program will not get you the expected baud rate other than 2.5MHz. For example, when you want to set baud rate to 115200, it requires 48MHz source clock, but now kernel runs UART at 160MHz.

Hi Bin,

what I'm seeing is that ttyS2's baudrate is always showing 115200 (from "stty -F /dev/ttyS2") no matter what value I change it to.

Thanks,

Leon

Hi Leon,

Are you not seeing the following? Note, I haven't modified the dts for 160MHz clk yet.

am62xx-evm login: root
root@am62xx-evm:~# stty -F /dev/ttyS5 2500000
root@am62xx-evm:~# stty -F /dev/ttyS5
speed 2500000 baud; line = 0;
-brkint -imaxbel

right, before changing it to 160MHz, it was like this. 

Okay, I will look into it next week. I don't think 160MHz refclk has been tested in Linux.

Thank you, Bin.

Sreenivasa, I don't really understand how this is related to the original issue.

The UART divider is definitely working well otherwise it won't be able to talk to the other device.

For 1Mbps, 1.5Mbps, 3Mbps, the baud multiple is always 16x (only different dividers), but the error rate increases. whatever the result 2.5Mbps is, this is an issue we need to figure out.

Thanks a lot,

Leon