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.
您好!
我想通过 UART 在嵌入式器件上刷写 CC3235SF、因为可通过定制 M12 (12引脚)连接器访问的引脚为 RxD、TxD、nRESET 和 GND。
测试证明命令行闪存在基于 Windows 的系统上正常工作。 (例如.
/SLImageCreator
image program --
file
<image_file.sli> --port <ttl-usb com port> --script_path .
)
这利用脚本将 UART DTR 线路作为复位信号触发。
遗憾的是、在 MacBook 上运行时、此确切命令似乎出现故障、我们需要使用 MacBook。 如下面给出的示例所示。
是否要设置某些权限以使其在 Mac 上可操作? 我是否需要专用驱动程序来通过 UART 进行刷写(通过通用 FTDI 芯片)? 或者、这是否是 Uniflash 中的错误?
此致、
Daniel
遗憾的是、Uniflash 专家今天不在。 应在明天发布答复。
谢谢、此致、
乔治
Daniel:
我将在支持 ImageCreater 的团队中进行回放、看看。 您运行的是哪个版本的 macOS?
此致、
John
John、
我们目前正在使用 MacOS BigSur v11.6。 当前安装的 UniFlash 版本为 v6.4.0.3394。
此致、
Daniel
Daniel、您好!
这是仅在 Mac 设备上使用--port 命令的已知问题。 如果未指定端口,自动检测是否适合您?
可以肯定、您使用的是 UniFlash 的哪个版本?
此致、
Sarah
嗨、Sarah
遗憾的是、自动检测也不起作用。 这是因为我们使用通用 FTDI 芯片通过 UART 刷写器件。
您是否知道是否有时间线在 Mac 上修复此错误? 您能为我们提供解决方法吗? 目前、我们在 Mac 上使用 Windows VM 来解决此问题、但这不是我们的可持续解决方案。
我们使用的是最新版本的 Uniflash :v6.4.0.3394
提前感谢
此致
Hans Habraken
您好、Hans、Daniel、
我正在检查此问题、但可能直到下周初才得到答案。 我会随时向您提供最新信息。
此致、
Sarah
您好、Hans、Daniel、
在我等待该响应时、您可以尝试 CC32xx SDK 中发布的 ImageCreator 可执行文件吗? 它是相同的命令行、但是与 SysConfig 工具一起使用的稍新版本。 您可以在 source/ti/drivers/net/imagecreator/bin 文件夹中找到 SLImageCreator.exe。
此致、
Sarah
你好,Sarah
即使在 CC32xx SDK 的最新版本(5_20_00_06)中使用 SLImageCreator 工具、也仍然存在相同的问题
您是否 已收到有关此问题的回复?
此致
Hans Habraken
您好、Hans、
我从工具团队获得了两条反馈:
此致、
Sarah
嗨、Sarah
我们已经在使用--script_path 选项来控制 DTR 行、以便在刷写之前复位器件(DTR 行连接到 CC3235SF 的 RST)。 如果您使用--port 选项(如果我没有弄错),这也是一个必需的参数。 关于配置文件、 我在 uniflash 文档中找不到任何说明如何配置 此 auto_detect_ex_FTDI.json 文件的参考。 您是否已经从工具团队那里听到过更多澄清信息?
此致
Hans Habraken
您好、Hans、
我仍在等待澄清、但无法保证自动检测选项正常工作。 重置脚本是更好的选择。
您可以共享脚本吗? 请注意、对于 Mac、需要以下命令:
serial.serialposix.TIOCSBRK = 0x2000747b serial.serialposix.TIOCCBRK = 0x2000747a
此致、
Sarah
您好、Sarah、
我们修改了 power_off 和 power_on 脚本、方法是添加所需的命令、如您所说、这会产生积极影响。 添加后、iotctl 错误消失、 Uniflash 能够复位器件(POWER_OFF 脚本)、设置中断信号、启动器件(POWER_ON 脚本)并清除中断信号。 我们还看到 Uniflash 可以连接到器 件、但当器件收到存储列表时、我们现在会看到读取数据的超时错误、如此屏幕截图所示。
我们通过将逻辑分析仪连接到通用 FTDI 芯片的 RST、TxD 和 RxD 进行了进一步挖掘。
此图表明 、Uniflash 能够设置与器 件的通信、但在 Uniflash 清除中断信号后、RST 线路被下拉、我们看到超时错误。 我们在 Windows 上看不到这种行为:
在清除中断信号后、Uniflash 会与器件通信、并且不会发生复位。
以下是我们的开机和关机脚本:
import time import serial import sys print("[power_on_com.py] - Setting RTS(0) = high (deasserting nReset)") self.port.setRTS(0) serial.serialposix.TIOCCBRK = 0x2000747a print("[power_on_com.py] - done") print("\n")
import time import serial import sys print("[power_off_com.py] - Setting RTS(1) = low (asserting nReset)") self.port.setRTS(1) serial.serialposix.TIOCSBRK = 0x2000747b print("[power_off_com.py] - done") print("\n")
是否知道为什么在清除中断信号后 Uniflash 会下拉复位线?
此致
Hans Habraken
您好、Hans、
我正在与工具团队进行核实、我将在星期二之前向您提供最新信息。
我注意到 在示例脚本 中使用了两个 break 命令。 您能否检查这是否会改变行为?
此致、
Sarah
您好、Hans、
工具团队为默认 XDS 设备提供了两个脚本、希望它们能提供帮助。 请检查 您自己的脚本中的 break 命令、并让我知道这是否解决了您的问题。
此致、
Sarah
你好,Sarah
我尝试在 power_off 和 power_on 脚本中添加两个 break 命令、但我仍然遇到相同的问题。 我还尝试了 您为默认 XDS 设备提供的脚本。 但问题是我们不使用 XDS 设备、因此我们会看到以下错误:
错误:无法连接到 XDS110 (-260)。
检查与 XDS110的 USB 连接。
我们的脚本基本上与您的脚本相同、唯一的区别是您假设器件连接到 XDS110探针、因此 XDS110Reset 脚本可用于复位器件。 我们使用的是自定义 FTDI 芯片、因此我们不能选择使用 XDS110脚本。 这就是我们直接驱动 FTDI 芯片的 RTS#引脚以在 power_off 和 power_on 脚本中复位器件的原因。 FTDI 芯片的 RTS#引脚连接到 CC3235SF 的 RST 引脚。
奇怪的是、这种行为只发生在 Mac 上、而不发生在 Windows 上、这让我相信 Mac 的 Uniflash 实例上存在某种错误。
您对我们如何在 Mac 上实现此功能有什么其他想法吗?
此致
Hans Habraken
您好、Hans、
尽管这些脚本用于不同的闪存器件、但 它们已在 Mac OS 上成功测试。
您是否还在 Windows PC 上使用相同的自定义脚本? 您的其余设置是什么?
此致、
Sarah
您好、Sarah、
很抱歉我迟到了。
是的、我们在 Windows PC 上使用相同的脚本(减去仅 MAC 所需的两个额外命令)、这是完美的。 我创建了一个有关我们设置的可视化演示文稿:
我们的 macbook 通过 USB A 型连接与 FTDI 芯片连接。 如上所示、CC3235SF 芯片(用于闪存)的必要线路暴露在外并连接到 FTDI 芯片。
我还创建了一个图、以可视化 Uniflash 执行的步骤:
由于我们不使用 XDS 芯片来刷写器件、因此我们需要一种方法将 CC3235SF 芯片引导至引导加载程序模式。 我们选择使用 FTDI 芯片的 RTS#线来复位 CC3235SF。 如图所示、Uniflash 执行 power_off_com.py 脚本以关闭器件。 在这里、我们使用`self.port.setRTS(1)`将 FTDI 芯片的 RTS#引脚设置为低电平。 在第3步中、Uniflash 会发送一个中断信号以告知器件在引导加载程序模式下引导。 在步骤4中、我们在 power_ON_com_script 中定义将 FTDI 芯片的 RTS#引脚设置为高电平、以便器件能够引导和检测中断信号。 我们可以在日志中看到、Uniflash 能够检测到器件的 ACK 响应、但随后会发生问题。 步骤5后、Uniflash 会将 FTDI 芯片的 RTS#引脚设置回低电平、器件在此状态下会断电、无法建立与器件的连接。 可以使用逻辑分析仪捕获此行为:
将 RTS#引脚设置回低电平的这种行为仅在基于 MAC 的计算机上发生。 我们在基于 Windows 的计算机上看不到这一点:
希望这将捕获我们的设置的图像。 如果还有其他问题、请告诉我!
此致
Hans Habraken
您好、Hans、
我的一位同事将在这里寻求支持。 由于本周的假期、他们的回复可能会延迟。
此致、
Sarah
您好、Hans、
此问题是否已解决? 当前状态是什么?
你(们)好
否、我们在基于 MAC 的机器上仍然遇到此问题
已理解、我将在内部联系以了解 macOS 为何将 RTS#线路设置为低电平。
您好、Hans、
我可以确认、在 Uniflash/ImageCreator 中不会手动控制 RTS。 在我看来、macOS 正在处理此行。
可能起作用的一点是: 在 Windows 中、高级设置中有一个选项"关闭 RTS 时设置"。 MacOS 应提供类似的选项。
你(们)好
我在 MAC 上搜索了一个等效的“在关闭时设置 RTS”UI 选项,但我找不到它.... stty 命令可能会起作用、但该命令似乎在 MAC 上未正确执行。 我还不明白在 Linux 容器中运行我们的设置的想法、但在这里、我很快就陷入僵局、因为在 MAC 上使用 Docker 无法在容器中安装串行设备。
您好、Hans、
对于 Windows、有这样的设置、请参阅 FTDI 的以下文档: https://www.ftdichip.com/Support/Knowledgebase/index.html?setrtsonclose.htm
我不确定我们是否还有太多其他支持、因为这些问题不再与 TI 的工具和软件直接相关。