[参考译文] TM4C123GH6PM：加电周期后波特率为9600的随机字符

苏普雷思

这似乎与您用于将 TTL UART 转换为 RS232电平的任何操作相关。 如何将 TM4C 连接到 PC？ 也许加电序列使得器件转换无法检测到速度？

您提到 Arduino 设置的成功、但适配器是否相同？ 尽管如此、Arduino 仍有可能在"更易于读取"5V 环境中运行...

关于您的代码、我只能建议在配置外设(GPIO、UART、任何内容)后、始终等待其可用。 例如：

SysCtlPeripheralEnable (SYSCTL_Periph_UART0)；
while (！(SysCtlPeripheralReady (SYSCTL_Periph_UART0)))；

另请注意：UART 通信之前的几个脏字符不会有太大问题、无论如何... 通信协议必须能够丢弃无效命令。

布鲁诺

您好 Bruno、

我使用 TM4C123GXL (Tiva C Launchpad)来编写固件。 默认情况下、UART0连接到板载 Stellaris ICDI、它作为 PC 上的虚拟串行端口提供。

感谢代码建议、我在初始化 UART0后已经插入了外设就绪检查、如上所述、但这并没有解决问题。

UART 通信之前的一些脏字符实际上不是问题。 但是、一旦器件通电、每次都需要按下 RESET 开关以在屏幕上显示实际字符。 在115200波特率下成功执行的原因对我来说仍然是个谜。

UART 很有可能检测一个从中间字符开始的字符。 如果字符是以特定方式形成的、并且足够紧密地一起发送、则可能会持续不同步。

看看插入小延迟是否会产生影响。 向上增大停止位也可能有所帮助。

Robert

您好 Bruno、
我将在一两天内访问逻辑分析仪。 我将使用结果更新论坛。 同时、我尝试更新固件、但无法从 TI 网站下载 UniFlash 或 LM Flash 编程器(显示504错误)。 还有其他替代链接吗？

苏普雷思
此处的链接似乎正常工作： processors.wiki.ti.com/.../Category:CCS_UniFlash

[引用 user="ethanil)]我认为 ICDI 硬件存在一些时序/上电问题。 无论如何我都要进一步测试它。我认为问题可能是 ICDI UART 接收器或 TM4C123GH6PM 发送器都没有 UART 信号上拉。 加电时 、TM4C123GH6PM UART 发送信号可能会悬空至不确定的水平、从而导致 ICDI 接收器看到一个字符的起始位。

 外部 RS232转换器可能会在接收信号上有上拉电阻、从而避免了问题的发生。

提出的最新理论(上拉 UART_TX)虽然是逻辑的、但似乎没有考虑到以下因素(事实证明)：

[引用 user="ethanil"]一旦设备通电，每次需要按复位开关才能在屏幕上显示实际字符。

现在、如果我们能够假设这些字符、"实际字符" 不是"非法字符"-上拉字符的缺失会导致"没有问题"。

和：

[引用 user="ethe Anil"]以115200波特率成功执行的原因对我来说仍然是个谜。

再次-如果 "成功执行" 意味着"w/out illegal characters"-缺少上拉 R、则"摘机"。   (作为嫌疑人被驳回)

作为调查人员、我们必须 "关注并回应所有 "证据中的事实"-即使不方便！"  

作为一般裁定/指导-建议在 UART_TX 上使用适当的上拉电阻器...   然而，根据现有的证据，"没有上拉 R @ UART_TX"似乎逃脱了， "有罪判决"--目前和现在！"

我也怀疑这是一个问题。 我认为 ICDI 很可能会混淆字符的开头并通过字节同步到点部分。 在这种情况下、增加停止位或每 n 个字节添加一个短暂停将改变行为。 短暂的暂停将允许正确的重新同步。 断点字符可能会执行相同的操作。

在较高的波特率下、您可能会很幸运地解决不匹配问题、或者来自微控制器的传输可能会有很小的延迟。 完全改变行为不会花费太多时间。

Robert

即使我尝试在电路板的 TXD 引脚上放置一个 PUR。 但它没有解决这个问题。 之前我尝试将停止位计数增加到2、但我没有成功。 每 n 个字节添加一个短暂的暂停可以解决这个问题、但我只是想找到极端的测试结果。 "如果具有相同设置的 Arduino UNO 硬件可以轻松地传输数据而不会出现任何延迟、为什么不使用 Tiva C "-这是我实验的灵感来源

[报价用户="ethe Anil"]如果具有相同设置的 Arduino UNO 硬件可以轻松地传输数据，而不会出现任何延迟，为什么不使用 Tiva [/报价]

请务必了解问题不在 Tiva 中！ 它位于中间器件中、用于将 UART 消息转换为 USB 虚拟串行端口！

您是否按照我之前的建议探测了焊盘上的 UART 线？

我的理论仍然是、如果您进一步等待、直到您开始传输消息、问题就会消失。 您同时为 Tiva 和转换器加电、并在转换器准备好执行其任务之前开始发送字节。

布鲁诺

[引用 user="Bruno Saraiva"]请务必了解 Tiva 中不存在问题！

您是否"绝对确定"了这一点？    愿意、"打赌场？"

 我们知道海报处理这个特定电路板的"什么都不知道"、也不知道他的 MCU 的状况、您是否同意？

我认为"需要更多信息"-在从"嫌疑人名单"中删除 MCU"之前。

考虑这一点-"中间设备"(您声称为"有罪")是否已"成功"海报的 Arduino？   那么呢？

绝对索赔/断言(大多数情况下)需要"绝对数据"-该数据尚未到达...

[报价 USER="CB1_MOBILE "]您是否"绝对确定"了这一点？    愿意、"打赌场？"[/引述]

这是一个非常简单的赌博，因为这是我们所讨论的海报农场，而不是我的农场。 我提出我的意见，他可以自由地接受。

[引用 USER="CB1_MOBILE "]是否"中间设备"(您声称为"有罪")已"成功地"了 Arduino 海报？ [/报价]

完全不可能：当他使用 Arduino 时、他肯定不使用 TI 的 Launchpad ICDI 串行转 USB 转换器、而是使用其他器件-可能是 MAX232模块、也可能是该 Arduino 板中已经包含的器件。

不过、这也是我要求(两次)该海报直接在 launchpad 的外露焊盘上通过逻辑分析仪探测目标 TM4C 发出的 UART 传输的原因、以便他看到 Tiva 真正产生的结果。 同样、我的推理是：ICDI 只不过是一个 Tiva 芯片、它除了接收 UART 字节并将其转换为 PC 的"虚拟 USB 端口"之外、还执行其他操作、 预计他在目标 TM4C 中的简短程序会在 ICDI 准备就绪之前开始从其中输出字节。 当 ICDI 的 UART Rx 最终唤醒时、字节已经在流动、接收器可以检测到通过一个字节的一半传输。

布鲁诺

我的朋友-其他证据中是否没有"太多"其他事实？

虽然我们的 JTAG/SWD 的"选择 Pod "是 J-Link (或更高版本)、但我们"已有数百次"使用"ICDI"、从未发现过海报的问题！ 我们使用了相同的9600波特率-(这个速率长期以来一直是我们以前的板的标准-当距离超过速度时。)

如果 ICDI“有罪”——这是你的“绝对要求”——难道这种情况不会“访问”多个国家吗——在这里？ 论坛搜索表明、这种情况并不普遍-甚至可能是任何提及都不会如此！

绝对索赔证明难以维持-打破这种习惯可能会证明富有成效...

大家好、

很抱歉耽误你的回答。 我没有使用任何逻辑分析仪、因为 SparkFun 的3.3V FTDI 线缆在暴露的 TXD 焊盘和 PC 之间连接时解决了这个问题。

谢谢您的反馈、Supreeth。

让记录显示"FTDI 线缆"是 TTL UART 转 USB 转换器：

无论问题是什么、它都在 ICDI 芯片中。 我仍然相信它在启动期间不同步、尽管有人认为、数千人使用 LaunchPad ICDI 用于 UART 之前可能会发出该标志。

目前还没有证据，但"证据"的说法是这样的。

布鲁诺

显然、您已经和许多其他人一起注意到了"R9-R10失败"、访问了所有"123 LPAD"用户、结果是"正在进行"、可能超过500个帖子！

然而，据我所知，“从不”有这样的“失败的@一个特定的波特率”文章出现在这里，也不出现在我活跃的“其他三个 ARM 论坛”中。

" PC 和 MCU 板之间的时序"和/或"USB 电缆"(在使用 FTDI 电缆时未使用)是否也证明存在怀疑？   此外-海报刚刚报道、"来自 SparkFun 的3.3V FTDI 线缆在暴露的 TXD 焊盘和 PC 之间连接时、解决了该问题。"    该电缆是否也应该连接到 RxD 焊盘？    

"正常/习惯"技术"证据中没有"任何"证明"、这将更好地支持您对 ICDI 的"绝对有罪"指控。    (尽管明显缺乏令人信服的、相互交织的事实、但情感是否会被锁定在您的诉求中？)

完全、完全和仅对该供应商的 ICDI 负责-证据不足-充其量也不成熟-并且(仍然)避免了测量要求-"您自己很关心、足够聪明、可以提出要求！")