[参考译文] CC3301：CC3301 和 STM32H753 上的 RAM BTL 下载问题

Other Parts Discussed in Thread: CC3301, CC3351MOD

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1598762/cc3301-ram-btl-download-issue-on-cc3301-and-stm32h753

器件型号： CC3301
Thread 中讨论的其他器件： CC3351MOD

我们目前正在移植 CC33XX-RTOS-MCU 驱动程序以在我们的产品中使用。 我们将 CC3301 与 STM32H753 搭配使用。 到目前为止bus_sendInitCommand、我们能够开始工作、并确认 POCI 在之后变为低电平、WLAN 中断和总线事务似乎也正常工作。

我们在下载 RAM BTL 时遇到问题。 在“----- 下载 RAM-BTL“部分、我们在 UART 输出中可以看到它正在向 WiFi 芯片发送数据包（“dnld 偏移：6 [...]“）。 但是、当它到达最后一个数据包“dnld offset：6 –65912-768"时“时、我们收到的下一条 UART 消息始终为“CommandSM：cmdStatus：cmd_ERR_TIMEOUT“、后跟“cmd_Send：命令 with error！ cmdStatus：0x8000581d“。 自然、等待 RAM BTL 上升失败、整体器件初始化也是如此。

SPI 总线仅通过 3MHz 运行、我们不会遇到任何间歇性问题。 它在 RAM BTL 二进制文件的最后一个数据包中始终失败。 由于我们在微控制器上使用的引脚不支持高电平有效中断、因此我们改为使用上升沿中断、并FwEvent_irq_handler在重新启用中断时调用该引脚是否为高电平。 我们修改FwEvent_irq_handler为采用布尔参数来指示它是从 IRQ 调用还是从调用wlan_IRQEnableInt、如下所示：

int FwEvent_irq_handler (const bool irq)
{
    TFwEvent *pFwEvent = gFwEvent;

    if(pFwEvent->eSmState != FWEVENT_STATE_STOPPED)
    {
        if (irq)
        {
            trnspt_RequestSchedule(pFwEvent->uContextId, TRUE);
            wlan_IRQDisableOnIRQHandler();//call adaptation layer
        }
        else
        {
            trnspt_RequestSchedule(pFwEvent->uContextId, FALSE);
            wlan_IRQDisableInt();//call adaptation layer
        }
    }
    else
    {
        ASSERT_GENERAL(0);
        return OSI_OPERATION_FAILED;
    }
    return OSI_OK;
}

我们尝试了几种不同的解决方案,包括将 RAM BM 下载错误解决方法的超时时间增加 ctrlCmdFw_ContainerDownload到 2000ms,但没有任何成功。

遗憾的是、我们无法使用我们的逻辑分析仪捕获所有 SPI 通信、因为它是一个较旧的模型、具有较小的缓冲器且无流模式。 因此、我们不能将其直接与 TI LaunchPad Sitara 示例上的通信进行比较。

您能帮助我们诊断这个问题吗？ 也许您以前遇到过这个问题？ 或者给我们建议我们可以尝试什么？