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.

[参考译文] AM3357:UART 驱动程序问题 — AM335X

Guru**** 2925550 points

Other Parts Discussed in Thread: AM3357

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1633431/am3357-uart-driver-issue---am335x

器件型号: AM3357

大家好:

当我们连接到散热模块时、我们发现了问题、因为我们有用户 MODBUS 接口(通过 RS485 接口控制器进行通信)、因此我们相应地修改了 DTS 文件。

我们注意到、有时当我们发送请求以从模块中获取响应时、我们会观察到添加了 NULL 字节 gettign、并且还发生了帧错误、这预计不会发生。

您能告诉我这可能是什么原因吗?

注意:

我们正在为我们怀疑使用的 UART 驱动程序的 AM335X 使用 TISDK 9.1(我希望问题也与之前的 TISDK 相同)

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

     Bin Liu 和 Remi Leveque Andreas Dannenberg1 我们有以下配置更改、

    &uart2{
    pinctrl-names =“default“、“sleep“;
    pinctrl-0 =<&RS485_pins_default>;
    pinctrl-1 =<&RS485_pins_sleep>;
    linux、RS485-enabled-at-boot-time;
    RS485-RTS-DELAY =<2 2>;
    RS485-RTS-ACTIVE 高电平;
    RTS-GPIO =<&GPIO0 22 GPIO_ACTIVE_HIGH>;
    状态=“正常“;
    };

    RS485_pins_default:pinmux_RS485_pins_default{
    pinctrl-single、pins =<
    AM33XX_PADF (AM335X_PIN_MII1_TX_CLK、PIN_INPUT、MUX_MODE1)
    AM33XX_PADF (AM335X_PIN_MII1_RX_CLK、PIN_OUTPUT、MUX_MODE1)  
    >;
    };

    当我们在逻辑分析仪中看到、在探测 TX 和 RX 时、我们正在正确接收数据、如下所示、这是来自转换器 (SN65HVD11DR) 的数据、

    我们  在应用中读取 NULL 字节、此外我们接收到损坏的数据、因为我们正在读取 10 个字节 的数据、并不是我们一直怀疑 UART 驱动程序添加该字节、因为它已由于差分信号的快速转换而在 DE/REdue 之间切换。 请帮助我们  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Manu:

    我将查看您明天提供的信息、然后返回给您。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Manu:

    您是否可以尝试&uart2 节点中添加“RS485-rx-during-tx“属性、以查看此操作是否能解决问题?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    还不错、会再来的 现在、根据我们的设计、我将 padmux 更改为上拉

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我们很快就找到了最重要的“根本原因“。 我们发现、RS RS-485 收发器的 RxD 输出在电路板上没有上拉电阻、以在 DE/重新未升高时保持悬空。 (请注意,在我们的设计中,DE 和 RE-NO 连接在一起、这在 RS RS-485 应用中很常见。) MANU 能够对焊盘多路复用器进行编程以提供上拉电阻、并消除了原始异常。 不过、在鉴定测试期间、我们发现了更多。 我们在 DE/重新禁止线路上看到两种不同的未指令信号情况、这两种情况下:(a) 有时会导致通信错误、(b) 即使它们不发出命令、也无法解释。

    1. 我们偶尔会在 DE/ RE-NOT 上看到短的正脉冲。 当它发生在接收数据包的中间时、它会窃取消息、强制进行不必要的重试。 当 RS RS-485 总线空闲时发生这种情况没有任何危害、但当然不应该发生。
    2. 我们有时还会看到、 在 传输的数据包完成后的很长时间内、DE/重新不会保持高电平。 在某些情况下、这种留存驱动器使能几乎到达总线上的回复。 同样,这种特殊的反常现象目前并不会造成我们的问题,但如果我们的下游模块回复速度稍快一点,那就会。

    这些异常似乎发生在驱动程序级别。 我们非常仔细地查看了应用层代码、但没有任何内容与 DE/RE-NOT 信号有关。 感谢您提供建议并帮助我们跟踪此问题。

    我们还问了焊盘多路复用器提供的可选上拉电阻的值。

    提前感谢您的帮助。

    John R. Graham
    Siemens

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、John:

    Bin 在 4 月 29 日之前不在办公室。 让我看看硬件团队中是否有人可以看一下。 请期待收到延迟的回复。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、John:

    在已知状态下、内部弱拉电阻可能无法抵消所连接器件的输入。

    检查您是否有机会添加外部拉电阻并执行测试。

    此致、

    Sreenivasa.  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Sreenivasa、

    首先、我们安装了适当的上拉电阻。 浮动 Rx 问题已立即得到解决。 通过实验、我们发现引脚多路复用命令的内部上拉具有相同的行为。 在这两种配置中、我最近报告的异常都在发生。

    此致、
    John

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、John:  

    谢谢你。

    也会尝试理解发生频率。 您是否在 每次发送数据或开始传输等时更新 DE/RE

    能否请您解释一下顺序。

    此致、

    Sreenivasa.

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    器件型号: AM3357

    继续访问 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1633431/am3357-uart-driver-issue---am335x 、该页面因我本人未回复而关闭。

    Kallikuppa Sreenivasa 写道:
    您好、John:  

    谢谢你。

    也会尝试理解发生频率。 您是否在 每次发送数据或开始传输等时更新 DE/RE

    能否请您解释一下顺序。

    此致、
    Sreenivasa.  

    ------------------------
    您好 Sreenivasa、

    发生的频率相对较低、也许我们在 RS –485 链路上发送的每一个视频十几条消息都是如此。 在我们当前的补丁版本中、我们重试从其中接收到损坏消息的器件命令、这几乎始终成功。 我们只是想找出根本原因。

    关于我们如何驱动 DE/RENOT 线路(电路板上的单信号连接在一起)、我们 没有。 我们的应用层代码都没有触及该信号。 所有这些都是在驾驶员层面处理的、因此我们正在寻找该层面的帮助/见解。

    我们看到异常的三个变体、 所有这些变体都与不应该是高的状态相关:

    1. DE 干扰为高电平、然后 任何传入的接收数据包之外恢复为低电平。 无害、但仍会引起担忧。
    2.  传入数据包的边界内设为高电平、然后恢复为低电平。 导致奇偶校验和/或成帧错误。 现在可以通过重试来缓解。
    3.   在传出命令数据包结束后、DE 保持高电平的时间过长、从而导致传入数据包损坏。 现在也会通过重试来降低。 

    此致、
    John

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、John:

    RTS-GPIO =<&GPIO0 22 GPIO_ACTIVE_HIGH>;

    是否在 GPIO0_22 引脚多路复用设置中启用了内部拉电阻?

    如果是、我想知道 DE 干扰问题是否由内核 UART 驱动程序框架引起。 是否可以修改电路板、以使用 UART2 本机 RTS 引脚进行 DE 控制、而不是使用 GPIO 引脚?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Bin Liu:

    在我自己的调查这个上个月的某个时候,我意识到我们的设计没有使用最正确/最自然的实现(本地 RTS )。 唉,我们已经交付了大量的产品,因此在这款产品上无法进行物流切换。 我们需要使用现有引脚来解决问题。

    我会让 Manu 来评论 pinmux 问题、但没关系、对吧? 从我们的 MSO 捕获结果来看、似乎很明显、DE 正在积极推动。

    此致、
    John

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bin Liu 是的、我们使用 GPIO0_22、该 GPIO0_22 配置为 DE_RE_SEL_1  、其启用为 PADCF 作为 AM33XX_PADF (AM335X_PIN_GPMC_AD8、PIN_OUTPUT_PULLDOWN、MUX_MODE7)

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    谢谢 Manu。

    您好、John:

    我记得几年前、我在较旧内核中调试了几个基于 RS485 GPIO 的 DE 引脚控制问题、发现问题是由于基于 GPIO 的 RTS 控制中的内核 UART 框架错误导致的。 我不记得有问题的内核版本、但解决方案是将 DE 迁移到本地 RTS 引脚。

    对于您的电路板上的这个问题、我想有两种调试方法:使用最新的内核进行测试或修改电路板以使用本机 RTS 来查看问题是否仍然发生。

    1.修改一个电路板以使用本机 RTS 查看 DE 引脚干扰是否仍然发生。 否则、GPIO DE 引脚干扰很可能由软件引起;

    2.将最新的内核移植到电路板上、看看 GPIO de pin 干扰是否仍然发生。 否则、这是一个已在新内核中修复的软件问题。 如果仍然发生这种情况、我们将从此处了解如何进行调试。

    由于原因、如果移植最新内核比修改电路板更轻松、您可以跳过#1 并直接测试#2。