[参考译文] AM3352：UART 在长时间运行后停止接收数据

尊敬的 Tony：

[报价 userid=“35100" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1626010/am3352-uart-stopping-receiving-data-after-long-time-running

#1。 在使用内核 3.12 的旧 SDK 上、UART 是否存在此类停止接收的已知问题。  

[/报价]

我不记得有任何与此类似的问题报告、尤其是在 RS RS-485 用例中。

[报价 userid=“35100" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1626010/am3352-uart-stopping-receiving-data-after-long-time-running

#2. 您对调查此类问题有何建议？  

 我可以考虑转储 UART 寄存器以查看是否有任何异常。  

 检查 GPIO 状态、以确认收发器是否方向正确。

[/报价]

是的、首先我们需要检查 GPIO DE 引脚在错误条件下是否处于正确的电平。

由于回显到 UART 的字符可以恢复该问题、因此 UART 驱动程序可能是正确的（客户使用 OMAP-Lerial.c，对吗？） 存在与时序相关的错误、该错误会将 GPIO 引脚置于错误电平以禁用 RS RS-485 收发器的 RX。

尊敬的 Bin：

是的、客户正在使用 OMAP-Lerial.c

#1：您是否在后续 SDK 版本中看到任何相关的更新/修复？

由于这很难重现（由于环境条件，客户自己的实验室最多可以连续运行 1 周，并且从未遇到过此问题）、只有最终客户的实际应用程序才会运行数周、100 个器件中大约有 1 个器件会在几周后随机出现此问题。

因此、对于他们下次在终端客户端重现的情况、我们需要提前准备一份步骤列表、以便在有限的时间内捕获尽可能多的信息（他们的最终客户可能无法长时间保留环境）。

#2:因此,如果您有任何其他要求,请提前告知我们。

谢谢、

Kevin

尊敬的 Kevin：

如果不知道问题的根本原因、就很难判断新 SDK 中的任何更新/修复是否有关联。

每当重现问题时、我们都需要进行检查

-如果 RS485 DE 引脚处于正确的水平,控制收发器接收数据;

-如果是这样,探测 AM3352 UART RXD 引脚,查看 RX 数据是否通过收发器。

尊敬的 Bin：

为了更好地做好准备、我们可以在下一个问题发生时高效地捕获所需的信息。今天下午、我们与客户合作、明确获取 RS485 DE 引脚状态的确切命令、并尝试使用他们自己实验室的正常产品。 请查看是否需要添加任何内容。

步骤 1：我们让客户提供下面的原理图、以清楚地说明哪个 GPIO 引脚控制 RS485。

从图片中可以看到 GPIO2_4 实际上控制 RS485 DE 引脚。

第 2 步：我们检查了 GPIO2 基地址为 0x481AC000。

步骤 3：我们认为 GPIO_OE（0x134 偏移）、GPIO_DATAIN（0x138 偏移）、GPIO_DATAOUT（0x13C 偏移）对于获得结果很重要

步骤 4：我们要求客户使用以下命令读取 GPIO2_4 的 GPIO_OE、GPIO_DATAIN、GPIO_DATAOUT

devmem 0x481AC134

devmem 0x481AC138

devmem 0x481AC13C

第 5 步：客户在实验室的正常电路板上执行了上述命令、并获得了以下结果：

root@Emerson:~# devmem 0x481AC134
0xFFFFFFEF
root@Emerson:~# devmem 0x481AC138
0x0000002E
root@Emerson:~# devmem 0x481AC13C
0x00000000

第 6 步：我们还让客户熟悉获取 dmesg 日志、以便他们能够在出现问题时获得正确的 dmesg 日志。 以下是客户在其实验室中获取的 dmesg 日志。

e2e.ti.com/.../dmesge.log

请您帮助检查以下几点：

#1：如果步骤 1~5 正确才能获得 RS485 DE 状态？ （特别是基于步骤 5 结果，表明产品当前按预期运行是否合理？）

#2：请检查步骤 6 dmesg 日志是否符合预期。 我们希望确保它是否涵盖了我们需要的预期信息。 例如、如果出现任何溢出问题或发生任何其他问题、是否会通过以这种方式获取在 dmesg 日志中？

问题 3：我们还认为、当出现问题时、可能倾倒一些 UART 寄存器也会很有用。 如其原理图所示、在这种情况下、客户正在使用 UART4、您是否还可以建议一些带有客户转储地址的 UART 寄存器？

谢谢、

Kevin

尊敬的 Kevin：

我将查看寄存器详细信息。 但首先、客户是否能够在问题发生时探测电路板上的 UART 信号？

我想我们首先需要探测 DE 引脚 (GPIO2_4) 以查看它是否为低电平。

如果该位为高电平、我们需要探测 UART4 TXD 引脚、以查看 AM335x UART4 是否不断发送数据。

如果 DE 引脚为低电平、我们需要探测 UART4 RXD 引脚、以查看该引脚上是否有 UART 数据位、这样我们就知道 RX485 收发器正常工作。

尊敬的 Kevin：

寄存器地址正确、但我不确定是否可以直接读取 DATAIN/DATAOUT 寄存器以获取引脚的状态。 我需要在 EVM 上进行检查。

定制电路板上 GPIO2_4 的引脚多路复用设置是什么？

我认为内核日志不会打印任何 UART 溢出信息。 您可能需要该程序 序列状态  https://github.com/TexasInstruments/serialcheck 中提供

您可能还想运行命令“ CAT /proc/tty/driver/serial “、查看是否提供了任何信息。

尊敬的 Bin：

客户正在使用 ZCZ 封装、因此引脚多路复用应为 U6。

谢谢、

Kevin

Kevin、

在 Linux 内核中写入此引脚 (U6) padconfig 寄存器的值是多少？  

您可能需要该程序 序列状态  https://github.com/TexasInstruments/serialcheck

中提供

我使用以下命令在目标板上构建了串行统计数据： root@am62xx-evm：/home/serialcheck-master # gcc serialstats.c -o serialstats

想要确认如何使用 serialstats、它是否持续监控状态、如果没有-o (once) 选项、如果没有错误、是否没有输出？

root@am62xx-evm:/home/serialcheck-master# ./serialstats --help
Usage: serialstats [OPTION...]
uart stats tool

-d, --device=FILE serial node device
-i, --interval=NUM interval in seconds
-o, --once print stats once and exit
-?, --help Give this help list
--usage Give a short usage message

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
root@am62xx-evm:/home/serialcheck-master# ./serialstats --device=/dev/ttyS0

^C
root@am62xx-evm:/home/serialcheck-master# ./serialstats --device=/dev/ttyS1
^C
root@am62xx-evm:/home/serialcheck-master# ./serialstats --device=/dev/ttyS1 -o
cts: 0 dsr: 0 rng: 0 dcd: 0 rx: 0 tx: 0 frame error 0 overuns 0 parity: 0 break: 0 buffer overrun: 0
root@am62xx-evm:/home/serialcheck-master#

尊敬的 Bin：

以下是我们读取引脚 (U6) padconfig 寄存器值的步骤：

步骤 1：U6 正在引用  GPMC_WEn CONTROL_MODULE 寄存器

第 2 步： 0.5 μ V 偏移 一半  GPMC_WEn  CONTROL_MODULE 寄存器为 0x898

步骤 3：控制模块的基地址为 0x44E10000

步骤 4：U6 padconfig 寄存器的地址将为 0x44E10000 + 0x898 = 0x44E10898

第 5 步：客户在运行电路板一段时间后、使用以下命令读取实验室中的值：

root@Emerson:~# devmem 0x44E10898
0x0000000F

。 0x0000000F 是写入 引脚 (U6) padconfig 寄存器的值。

谢谢、

Kevin

尊敬的 Bin：

我们让客户进行了测试  CAT /proc/tty/driver/serial 、获得了以下结果：

root@Emerson:~# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:unknown port:00000000 irq:0
1: uart:unknown port:00000000 irq:0
2: uart:unknown port:00000000 irq:0
3: uart:unknown port:00000000 irq:0

我们认为原因是、在使用的 SDK3.x 客户中、 DTS 不受支持。

作为一种权变措施、我们认为最准确且可靠的方法是读出所有与错误相关的寄存器以查看是否发生了任何错误。 我们创建了以下步骤供客户在问题发生时尝试、请检查、谢谢。

第 1 步： 基址 对于 UART4（客户使用）是 0x481A8000

步骤 2：  LSR_UART （偏移 0x14）记录  OE （超限错误）、 PE （奇偶校验错误）、和 Fe （帧错误）

第 3 步：除了  LSR_UART 、我们认为  IER_UART（偏移 0x4）、 IIR_UART （偏移 0x8）、LCR（偏移 0xC）、 MCR（偏移 0x10）和 TLR（偏移 0x1C）也有助于分析、我们将让客户在发生问题时读出这些寄存器、以支持我们的进一步分析。 您认为这可以取代  “ CAT /proc/tty/driver/serial “？

LSR_UART（偏移 0x14）：  devmem 0x481A8014

IER_UART（偏移 0x4）：  devmem 0x481A8004

IIR_UART（偏移 0x8）： devmem 0x481A8008

LCR（偏移量 0xC）： devmem 0x481A800C

MCR（偏移 0x10）： devmem 0x481A8010

TLR（偏移 0x1C）： devmem 0x481A801C

谢谢、

Kevin

尊敬的 Tony：

它是否持续监控状态、如果没有-o (once) 选项、如果没有错误、则不会输出？

如果没有'-o'参数、程序会每 10 秒打印一次消息（如果也没有使用'-i'）。 您可以使用'-i'指定打印间隔。

尊敬的 Kevin：

我们已让客户进行测试  CAT /proc/tty/driver/serial 、并获得以下结果：

此结果没有任何有用的信息。

第 2 步：  LSR_UART （偏移 0x14）记录  OE （超限错误）、 PE （奇偶校验错误）、和 Fe （帧错误）

OE、PE、FE 反映接收到的特定字节的错误。 一旦从 UART RX FIFO 中读出了字节、寄存器值就会复位。 因此、我不确定这些信息是否有帮助。 但是、错误状态已记录在内核内部数据结构中、该结构可由上述“erialstat"程序“程序查询。

顺便说一下、在读取 DE 引脚 (GPIO2_4) 状态时、请使用其 DATAOUT 寄存器 (0x481AC13C)。 DATAIN 寄存器不会指示 GPIO 引脚输出电平。

此结果没有任何有用的信息。

输出是否应至少具有 IRQ 计数？ 由于此命令没有任何计数输出 、因此似乎是该命令  CAT /proc/tty/driver/serial “不会生效。

Kevin Peng 

serialstats.c 只是读取  TIOCGICOUNT 计数并进行打印。 如果可以在目标系统上成功构建、则它应该独立于 Linux 版本运行。  

[报价 userid=“35100" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1626010/am3352-uart-stopping-receiving-data-after-long-time-running/6275829

输出是否应至少具有 IRQ 计数？ 由于此命令没有任何计数输出 、因此似乎是该命令  CAT /proc/tty/driver/serial “不会生效。

[/报价]

我们可以忽略此 procfs 条目。 多年来我一直未提及 OMAP-Lserial 驱动程序、现在我不确定此 procfs 条目是否涵盖了该驱动程序。 我们可以从/proc/interrupts.获取 IRQ 计数

如果可以在目标系统上成功构建、它应该独立于 Linux 版本运行。  [/报价]

仅供参考、您还可以使用 32 位 (ARMv7) 工具链在主机 PC 上对其进行交叉编译。

尊敬的 Bin：

客户今天刚刚在其终端客户方面重现了此问题。

请查看以下日志、了解寄存器转储：

devmem 0x481A8014;devmem 0x481A8004;devmem 0x481A8008;devmem 0x481A800C;devmem 0x481A8010;devmem 0x481A801C;devmem 0x481AC134;devmem 0x481AC138;devmem 0x481AC13C
Bus error
Bus error
Bus error
Bus error
Bus error
Bus error
0xFFFFFFEF
0x0000002E
0x00000000

谢谢、

Kevin

总线错误似乎告诉 UART 模块进入暂停状态。 请将此电路板保持在此故障状态下、我明天将在 EVM 上进行实验、然后告诉您使用 Linux sysfs 中的命令来检查 UART 运行时 PM 状态。

devmem 0x481AC134；devmem 0x481AC138；devmem 0x481AC13C

这 3 个寄存器是什么 — 0x481AC13x？

[引用 userid=“7730" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1626010/am3352-uart-stopping-receiving-data-after-long-time-running/6284460

devmem 0x481AC134；devmem 0x481AC138；devmem 0x481AC13C

这 3 个寄存器是什么 — 0x481AC13x？

[/报价]

没关系、它们用于 GPIO DE 引脚。

今天下午我让他们检查 UART4 的状态：  devmem 0x44E00078

Tony、

是的、您比我更清楚

UART 似乎处于运行时暂停状态、并且其时钟选通。

尊敬的 Bin：

由于 UART4 状态寄存器转储有总线错误、我们怀疑其时钟是否正确启用。 因此、我们在下面提供了完整的寄存器转储以确认：

CM_WKUP_UART0_CLKCTRL:  devmem 0x44E004B4
0x00000002

CM_PER_UART1_CLKCTRL:   devmem 0x44E0006C
0x00000002

CM_PER_UART2_CLKCTRL:   devmem 0x44E00070
0x00000002

CM_PER_UART3_CLKCTRL:   devmem 0x44E00074
0x00000002

CM_PER_UART4_CLKCTRL:   devmem 0x44E00078
0x00030000

CM_PER_UART5_CLKCTRL:   devmem 0x44E00038
0x00030000

CM_PER_GPIO2_CLKCTRL：devmem 0x44E000B0
0x00000002

参阅下图、可看到 UART4 时钟因一些原因被禁用。 (UART5 也被禁用、因为它们在 SW 中未启用、客户仅使用 UART4)

我们经过双重确认、允许客户读取 UART5 状态寄存器和 UART2 状态寄存器希望看到 UART5 有总线错误、UART2 可以成功读取状态以再次确认 UART4 状态总线错误是因为时钟因某种原因被禁用：

UART 5:
IER UART (Offset 4):   devmem 0x481AA004
Bus error
IIR UART (Offset 8):   devmem 0x481AA008
Bus error
SPR (Offset 1C):       devmem 0x481AA01C
Bus error

UART 2:
IER UART (Offset 4):   devmem 0x48024004
0x00000005
IIR UART (Offset 8):   devmem 0x48024008
0x000000C1
SPR (Offset 1C):       devmem 0x4802401C
0x00000000

该结果证明了我们的假设、原因是 UART4 时钟被禁用、导致寄存器转储中出现总线错误。

已应用 serialstats 工具 、输出如下：

root@am33x:~ ./serialstats --device=/dev/ttyO4 -o   
cts: 0 dsr: 0 rng: 0 dcd: 0 rx: 396082106 tx: -2106099644 frame error 0 overuns 0 parity: 0 break: 0 buffer overrun: 0
root@am33x:~ ^C
root@am33x:~ ./serialstats --device=/dev/ttyO4 -o   
cts: 0 dsr: 0 rng: 0 dcd: 0 rx: 396082106 tx: -2106099644 frame error 0 overuns 0 parity: 0 break: 0 buffer overrun: 0
root@am33x:~ ./serialstats --device=/dev/ttyO4
cts: 0 dsr: 0 rng: 0 dcd: 0 rx: 0 tx: 0 frame error 0 overuns 0 parity: 0 break: 0 buffer overrun: 0
cts: 0 dsr: 0 rng: 0 dcd: 0 rx: 0 tx: 0 frame error 0 overuns 0 parity: 0 break: 0 buffer overrun: 0
cts: 0 dsr: 0 rng: 0 dcd: 0 rx: 0 tx: 0 frame error 0 overuns 0 parity: 0 break: 0 buffer overrun: 0

//The output without -o option are 0 is correct, as it is (new_counters.x-old_counter.x) in while(1), there is not increament. so 0.

该工具中似乎没有记录明显的错误。 系统 奇怪的是 Tx 是负数。 它是否有任何潜在影响？

CAT /proc/tty/driver/OMAP-SERIAL 要确认状态：输出与 serialstats 相同。

root@am33x:~ cat /proc/tty/driver/OMAP-SERIAL
serinfo:1.0 driver revision:
0: uart:OMAP UART0 mmio:0x44E09000 irq:88 tx:39039 rx:0 RTS|CTS|DTR|DSR
1: uart:OMAP UART1 mmio:0x48022000 irq:89 tx:0 rx:0 CTS|DSR|CD|RI
2: uart:OMAP UART2 mmio:0x48024000 irq:90 tx:0 rx:0 RTS|CTS|DTR|DSR
3: uart:OMAP UART3 mmio:0x481A6000 irq:60 tx:0 rx:0 CTS|DSR
4: uart:OMAP UART4 mmio:0x481A8000 irq:61 tx:-2106099644 rx:396082106 RTS|CTS|DTR|DSR

完整的 dmesg 日志、如下所示：

e2e.ti.com/.../4718.session3.log

有 3 行显示 UART_Open、因为当时客户使用了 serialstats 工具、因此没有问题。

您对进一步调试有什么建议吗？

谢谢、

Kevin

尊敬的 Kevin：

在 EVM 上运行内核 3.12、然后我执行了以下命令：

  #查找/sys -name '*.serial'

并得到：

  /sys/bus/platform/devices 44e09000 .serial
  /sys/bus/platform/drivers/omap_uart 44e09000.serial
  /sys/devices/ocp.2/44e09000.serial

其第一行 44e09000.serial“用于控制台 UART0。 但是、如果您在启用 UART4 的定制电路板上运行此命令、还应获得：

  /sys/bus/platform/devices 481a8000 .serial

对于 UART4、立即运行命令：

  # cd /sys/bus/platform/devices 481a8000 .serial/power/

然后运行命令：

  # cat 控制

我希望您得到：

  自动

运行命令：

  # cat runtime_status

我希望您得到：

  已暂停

它通知 UART4 处于暂停状态。 最后运行命令：

  # cat autospend_delay_ms

我在 EVM 上看到了“-1"，–1，但“但我、我想知道您是否在定制电路板上看到了正值。

最后、请运行命令：

  #回声开启 >控制

在定制电路板上、然后检查是否使 UART4 恢复运行状态。

如果是、则此问题的最终解决方案是在 Linux 引导后且应用程序启动之前执行“echo on > control“。

尊敬的 Bin：

感谢您对客户在线会议的支持。

我们需要了解 3 个要点：

1：根据您在会议上的建议修改暂停功能。 我们与客户合作并获得 示例 以下内容。 请 请检查一下 如果一切都正常、谢谢。

e2e.ti.com/.../6710.my_5F00_code_5F00_change.patch

2：客户有这样的想法 下一次出现设备重新出现问题 、客户计划应用  ECHO ON > CONTROL 、如果是 UART 立即恢复 之后、如果我们提前应用此命令、客户将更有信心能够解决问题。 （这是客户的想法，但我担心的是，如果此命令的功能是尝试防止 UART 暂停、那么如果它已经暂停、它可能没有恢复 UART 的功能？ 您如何看待这一点？）

3：客户还计划 在后台编写一个脚本、持续读取 UART 时钟寄存器、以检查它是否已启用、如果未启用、则通过写入来启用它。 （客户的想法是这样，但我们的担心是如果 UART 已经暂停，那么只写入时钟来启用可能还不够，我们可能还需要驱动程序初始化，您怎么认为？）

谢谢、

Kevin

尊敬的 Kevin：

1:基于您在会议上修改暂停功能的建议。 我们与客户合作并获得 示例 以下内容。 请 请检查一下 如果一切正常、谢谢。

补丁在功能上正确。 但我建议使用 dev_warn () 而不是 printk ()。 您可以参考 OMAP-Lerial.c 中的其他位置、了解如何使用 dev_warn ()。 DEV_WARN() 将在消息中打印 UART 端口地址、因此打印消息中不需要 up->port.line。

在客户端测试此修补程序时、由于“autospend_delay_ms"设置“设置为–1、因此不应调用 serial_obap_runtime_suspend() 函数。 我想客户是否可以手动将 autospend_delay_ms 更改为正数（例如 100ms）、并且不将数据传输到 UART 端口、以查看控制台上是否显示 printk () 消息。

2：客户有这样的想法 下一次出现设备重新出现问题 、客户计划应用  ECHO ON > CONTROL 、如果是 UART 立即恢复 之后、如果我们提前应用此命令、客户将更有信心能够解决问题。

我认为这是一个好主意。 当一切正常运行时、当模块已经处于运行时暂停状态时、将控制权从自动更改为开启将立即恢复模块。

同样、由于我们不知道时钟门控是什么、因此我们无法判断这是否能够防止该问题。 我们必须对其进行测试和查看。

3：客户还计划 在后台编写一个脚本、该脚本持续读取 UART 时钟寄存器、以检查是否已启用、如果未启用、则通过写入来启用它。

这种可能性不大。 软件（内核）具有自己的状态机、只需修改 UART 时钟控制寄存器即可更改/校正状态机。

尊敬的 Bin：

请查看以下更新：

客户已遵循了您的建议、对于 serial_OMAP-LSUSPEND 和 serial_OMAP_runtime_suspend 函数、将 printk() 更改为 DEV_warn ()、如下所示：

然后、客户进行以下 3 个实验：

1：  当 control 设置为 auto 并 autosuspend_delay_ms 设置为 10000 时 、如果串行端口超过 10 秒未接收数据、将在代码中打印以下消息：

[  101.289096] omap_uart 481a8000.serial:  serial_omap_runtime_suspend uart port num = 4

此时、UART4 的寄存器保持正常（如下所示为 0x00000002）、表示代码补丁有效 阻止串行端口进入运行时暂停 （使用未打补丁的内核进行交叉验证，其中寄存器值在暂停后变为 0x00030000）。

root@Emerson:/sys/bus/platform/devices/481a8000.serial/power# devmem 0x44E00078
0x00000002

2： 当 CONTROL 设置为 ON 且 autospend_delay_ms 设置为时 10000 、如果串行端口超过 10 秒未接收数据、则不会打印代码中的消息。

UART4 寄存器也是正常的、这表明将控制设置设为 ON 具有更高的优先级、以防止系统暂停功能、即使 autospend_delay 不是–1 且未接收到数据也是如此。

3：输入  echo freeze > /sys/power/state 来放置 进入睡眠状态  （要测试 serial_OMAP-LSUSPEND 功能，没有运行时）、会生成以下日志：

[   56.404467] omap_uart 481a8000.serial:  serial_omap_suspend uart port num = 4

此时、UART4 的寄存器保持正常、表明代码补丁有效地阻止串行端口进入系统暂停状态。

root@Emerson:/sys/bus/platform/devices/481a8000.serial/power# devmem 0x44E00078
0x00000002

总体结果似乎是有希望的、关于测试 3、其他模块是否也会进入暂停功能？

谢谢、

Kevin

尊敬的 Kevin：

这个补丁对我来说很好。 顺便说一下,你现在不再需要打印 up->port.line ,因为 dev_warn() 将 UART 基址打印为日志前缀（如消息中的 481a8000.serial ）,所以我们已经知道哪些 UART 打印消息。

关于测试 3、其他模块是否也会进入暂停功能？

不会、任何模块拒绝暂停都会导致整个 Linux 完全不会暂停。