[参考译文] CC3351MOD：RAMBTL /conf 文件下载问题

SWRA779 表示仅支持模式 0、但我们仅在模式 3 下从目标获取回复。 无论我们编程到 CPOL 中、CLK 始终处于空闲状态高电平。

您好、

您似乎无法通过 BTL。

我只能将 CPOL/CPH 设置为 0/0 时使用。

这也是启动期间发送到芯片的第一个命令。

我看不到在逻辑 BFFC ,事实上,即使时钟看起来很奇怪。

有没有机会你有 Saleae 逻辑?

Shlomi

谢谢 Shlomo。 我们已解决 SPI、现在处于模式 0。 ST 库需要将一个显式位设置为 CPOL/CPHA 以初始化为正确状态（否则，它们仅在 CS 下降后的第一个 TX 上初始化为 0）。 捕获的行为相同、但我们现在会在目标上造成崩溃的时间更长。 它无法返回 RAM_HINT_SEsecond_loader_init_complete。

时钟正确。 逻辑分析仪上的 100MHz 采样率意味着其显示的占空比为 60：40。 这是 LA 的一个限制。

解码器正确显示、例如 BFFC：

您好、

虽然使用此分析仪很难工作、但您至少能将整个捕获、而不仅仅是屏幕截图吗？

我需要在中断之前/之后立即查看完整的过程。

此致、

Shlomi

e2e.ti.com/.../saleae_5F00_cc3351_5F00_init.zip

已交付 Saleae、请参阅随附并应用了干扰滤波器

您好、

逻辑似乎很奇怪。 它刚开始下载 RAM 引导加载程序、但 0xBFFC 的状态没有意义、因此可能是 Saleae 或物理线路有一些问题。 我还可以在末尾看到它发送 0xBFFC、这应该对应于中断、但我可以看到两种情况下它被从蓝色表面发出。

此外、时钟在每次新事务时启动时都保持稳定、但随后开始抖动。

为了供您参考、我附加了它应该是怎样的。

此致、

Shlomie2e.ti.com/.../initialization_5F00_ThickMAC_5F00_v310_5F00_R8.sal

这是非常有帮助的 Shlomo。 我们正在寻找一个捕获,但找不到一个捕获。 如果我们有进一步的问题、我们将与我们联系、如果解决了问题、我们将报告修复程序。

好的、听起来不错。

时钟抖动是 250MHz 采样率下的一个样本。 我们不会期望比这更好。 您发现了什么？

IRQ 配置出现问题。 我们发现、在 ST 平台上、我们需要启动时的上升沿 IRQ、或者在 SDIO-to-SPI 切换后第一个 INIT 命令失败。 现在、我们检查哪个边沿发出了 IRQ、并禁用上升沿（如果是触发器）。 这让我们得到了我们假设的下载 BL 事务（0xboo7c0de 无论如何都在有效载荷中）。

我们注意到、尽管传输大小相同（234 * 32b 传输）、但我们的有效载荷与参考有效载荷不同。 然后、请求状态的间隙为 53usec、而基准捕获为 163usec、IRQ 已上升。 状态回复是相同的、但参考捕获在状态读取时有一个下降 IRQ、而我们的捕获目前尚未发出 IRQ。

然后、两次捕获均从目标读取、直到不忙。 我们的捕获会在当时引发 IRQ、但超时。 参考捕获从目标读回并继续。

请查找随附的当前捕获。  任何进一步的建议都将是非常受欢迎的。  e2e.ti.com/.../cc3351_5F00_bringup_5F00_irq_5F00_corrected.zip

您好、

我不清楚的是、为什么在进程停止/中断之前、主机在中断触发之前发送 0xBFFC。

它是否与 EDGE IRQ 相关？

您可以看到、作为对此 0xBFFC 的响应、状态为 0x0、而不是按预期显示 0x2。

此致、

Shlomi

在我们的捕获中、在 2.0476 秒时、对 BFFC 的响应为 3（初始 0 后）。 这与 8.27948 处的参考捕获相同、也是 0 后 3 处。

但在参考捕获中、BFFC 似乎会导致 IRQ out。 在我们的捕获中、IRQ 未就绪、也没有丢弃。 因此、在将数据包传输到 cc3351 之后、就没有要处理的 IRQ。 在参考捕获中、BFFC 提供 IRQ、该值在数据包传输后似乎会导致不同的情况发生、并且基准在 8.27964 处发出 BFF8。 我们没有 IRQ 的捕获挂起。

我试着解释一下通常流程是什么、以及如何查看从 0xBFFC 返回的状态。

基本上、0xBFFC 应仅在接收到中断时触发。

参考捕获始终是这种情况。

在您的示例中、当 IRQ 线路为低电平时、存在一个 0xBFFC 触发器。 这不应该发生。 这是我问的。

因此、返回的状态为 0。

查看状态的方法是查看响应的第 29 个 int32。

在主机驱动程序代码中、您可以看到名为 FwStatus_t 的结构

typedef 结构__packed__｛
uint32_t block_pad[28]；
uint32_t HOST_INTERRUPT_STATUS；
uint32_t rx_status；
CORE_FW_STATUS_t fwInfo；
uint32_t TSF；
｝FwStatus_t；

HOST_INTERRUPT_STATUS 是器件返回的状态。

在固件下载期间、您应该得到 2 个、表示 HINT_COMMAND_COMPLETE。

查看您获得的内容的屏幕截图：

Shlomi

谢谢 Shlomo。 根据 WLAN_IRQ_ADAPT.c 中的注释、我们的实现从下降沿触发开始、但观察基准捕获可以发现它似乎是上升沿（在 BFFC 回复期间复位为低电平/空闲）。 我们在 CC3351MOD 上的转换器 3V3 侧进行测量。 您能否证实这是哪一个？ 我们无法在硬件指南中找到关于极性的明确确认。

今天上午、我们重新配置为上升沿。 虽然 IRQ 计数保持不变、但我们可以看到 BFFC 现在仅跟随上升沿、与采样相同。 发送第二阶段 BL 的第一个数据包（根据磁盘上的文件进行验证）后,我们得到了与参考相同的状态回复,但我们的最终状态回复没有设置位 2 ,我们在邮箱读取 BFF8 后超时。

还有第二个区别、这可能无关紧要、但在参考捕获发送其最终的 2x32b 数据值之前存在一个很短的差距、我们没有这一差距。 发出的总时钟数是相同的。 也许无关紧要、我们不知道。

附件包括 pcap、我们认为它不会显示错误、日志 PIN 在 Saleae 捕获中。

e2e.ti.com/.../cc3351_5F00_init_5F00_rising_5F00_edge.zip

抱歉、Shlomo、我们现在在上面的捕获中看到 0x02。 我们认为、到 BFF8 读取结束时、我们的数据包现在与参考匹配、在这种情况下、我们的最终 32b 值与参考值不匹配、捕获结束。

您好、

很高兴知道我们正在取得一些进展。 现在它看起来更好。

最后一个字节只是 TSF（时钟）、因此即使在同一器件上、不同运行之间也可能会有所不同。 则可以忽略这些错误。

从这里开始、下一个预期的命令应该是下一个块 (0xBFF0)、但由于某种原因、我在捕获中看不到它。

几乎看起来主机端没有推动下一个块。

您能解释一下原因吗？

PC 在主机端的什么位置？

此致、

Shlomi

感谢您的更新 Shlomo。 是的、我们希望/怀疑 TSF 是设备时钟。

我们同意、捕获表明接下来应该有更多的块。 附件中的文本文件表明在发送 BL 的第一个块后没有收到来自目标的回复（应该是提示块接收,我们认为?）。 就会像以前一样发生超时和故障。 我们还在 zip 中包括了 pcapng 和 saleae 捕获,以防有任何进一步的线索。

不过、在顶层、固件加载应在 0x43ff0000 回复 BFF8 之后继续。 参考捕获会立即继续到 BFF0 和另一个块。 我们没有更改引用中可能停止任务的任何其他内容（例如 malloc，任务栈大小）-实际上命令日志表明它按预期运行。 当然、SPI 和 IRQ 代码没有问题、我们有硬编码的 BKPT 指令来停止错误/ FreeRTOS 超时。 您可以提出的任何建议、我们很乐意进行调查。

编辑：忘记回答 PC 问题。 我们在基于笔记本电脑的 STM32CubeIDE 中进行开发。 调试器、FTDI CDC 和 CC3351 电源均来自监控器 USB 集线器（STM32 在其 5V 电源轨上没有足够的功率）。 Saleae 直接连接到笔记本电脑的 USB 端口。 我们位于英国。 这个问题能回答吗？

e2e.ti.com/.../23_2D00_01_2D00_26_2D00_captures.zip