[参考译文] MSPM0L1306：MSPM0L 器件缺陷

尊敬的 Patrick：

在器件勘误表中、我没有看到任何提到这是一个已知问题。

我想知道他们是如何测量这个频率的？ 它们是否在探测 CLKOUT 引脚？ 发送器和接收器是否使用相同的波特率？ 您能和我分享 SysConfig 中的 UART 配置吗？

此致、

Owen

来自客户：

“我‘将内核时钟频率驱动到“clk_out"引“引脚来验证内核时钟频率、并使用示波器对其进行测量。 使用 24MHz 的 USER_TRIM 设置时得到了 24MHz。 未使用 USER_TRIM 设置时得到了默认的 32MHz。

我使用的 syscfg 实用程序版本没有明确提供为传输和接收设置单独波特率的方法。 如果 Gary 批准、我可以提供 syscfg 文件、但我附加了 UART 的常规设置。 SYSCFG 根据时钟树设置自动假设内核时钟频率。 在附件中、您可以看到、用户修整设置为 24MHz 时、syscfg 的 UART 部分也会假定 24MHz。 在自动生成的代码中、您可以找到生成的标记为..24MHz 的分母。 或..32MHz。 这取决于时钟树选择。 我还检查了分频值、并且它们与假定的频率源和波特率相匹配。 syscfg 工具本身没有任何问题。

只有在 BUSCLK 使用 USER_TRIM 设置时、我才会发现馈送到 UART 模块每一侧的视在时钟不同的问题。 我最想说的是、我可以通过关闭 USER_TRIM 设置来始终确保正确运行、而 syscfg 中没有其他更改。 在 32MHz 上运行的示例。 在 USER_TRIM 设置为 24MHz 的情况下、TX 和 RX 波特率总是不匹配。 我可以使用弱定义的 syscfg 方法将 32MHz 设置强制进入接收侧并使其接收、但随后发送侧会过度分频、产生不正确的波特率。“

尊敬的 Patrick：

感谢您提供的信息、我将尝试在我这边复制问题、并在收到回复后立即回复您。

此致、

Owen

谢谢 Owen！

尊敬的 Patrick：

我只是想向您介绍一下这种情况。 我还能够重现与客户类似的问题、但我的问题是在 UART 的 TX 端观察到的。 我将与设计团队一起研究这一点、以了解这是预期行为还是器件问题。

此致、

Owen

尊敬的 Patrick：

与设计团队讨论后、我们观察到的行为是预期行为。  

此致、

Owen

尊敬的 Patrick：

只是想提供另一个跟进。 如果客户希望使用 24MHz 时钟运行、问题可能是 SysConfig 未配置器件、因此不会禁用 asnyc 快速时钟请求。 那么、发生的情况是波特率是根据 32MHz 时钟而不是 24MHz 时钟计算得出的。 他们可能会尝试设置该位、看看这是否会改变状态。

此致、

Owen

Patrick、对 Li 上次关于  asnyc 快速时钟请求的评论有任何更新？  谢谢、Gary