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.

[参考译文] CC1310:用于大型 SPI 事务的 CPU "暂停"

Guru**** 2481465 points
Other Parts Discussed in Thread: CC1310

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1288178/cc1310-cpu-halts-for-large-spi-transactions

器件型号:CC1310

您好!

对于长度超过840字节的 SPI 事务、我遇到了一个奇怪的问题。

对于840字节或更短的长度、我看到预期的行为:

  1. 主器件将 CSZ 拉至低电平
  2. CC1310通过拉低"SPI 就绪"进行响应
  3. 主时钟 CC1310之外的840字节(MISO 字节看上去均正常)
  4. 主器件使 CSZ 无效
  5. CC1310 SPI 回调函数执行
    1. CC1310切换示波器布线的 GPIO
    2. CC1310使"SPI 就绪"无效

事务长于840字节时、不会执行步骤5、并且主执行线程看起来是 GOOD AWOL (即 SEG-FAULT/STACK 腐败?)。

我已经附加了成功(840字节)和失败(844字节)的捕获跟踪:

  • MAP 文件(请参阅摘录、 已连接 )显示了要发送 SPI 字节的 SPI 缓冲区位于.bss 段的开头、地址为0x20000520、其大小为0x1830 (= 6192)字节、足以存储我要发送 SPI TX 的844个字节。
  • 在设置844字节 SPI 传输之前、我调试"print" spi_Transaction.txBuf、.rxBuf 和.count 参数、这确认我请求 从正确的位置发送正确数量的数据。
  • 一旦建立了 spi_transfer (),主执行线程只需永久地切换 GPIO (即在 while (1){;}循环中):
    • 成功 (840字节)事务时、此 GPIO 切换被回调触发打断、这会切换一些报告 SPI_Transaction .status 的不同 GPIO。
    • 发生故障(844字节)事务时、此 GPIO 切换仅在主器件使 CSZ 无效且没有证据表明 CC1310中具有后续活动时停止。

请注意以下几点:

  • MISO 上的字节值始终存在且正确、即 SPI 事务 实际上已经完成、我只是没有看到发生任何回调。
  • 840字节实际上 上限。 也就是说,这不是的情况下844是一个神奇的数字和其他更大的数据包长度工作(我已经尝试了,例如848, 860, 900-所有失败与相同的症状)

对我来说、这些症状看起来像是数据中止/ SEG-FAULT 或堆栈溢出、但我不知道如何进一步调查。 遗憾的是、我无法使用 TI 调试器、因为我的主 CPU 似乎以某种方式与调试器争夺对 CC1310的控制权。 我有:

  • 将用于运行主线程的任务的堆栈大小从1024字节增加到2048字节、但没有改善。
  • 将 SPI 数据缓冲区重新定位到了0x20000600、远离我注意到的 dmaSpi[01][RT]xControlTableEntry、它位于.bss 段之前、没有任何改进。

请告知。

TIA、


Sean。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Sean、您好!

    感谢您的详细描述。

    我看到您在2年前发布了一条类似的主题、这两者之间是否有很小的关联性?

    https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1049749/cc1310-spi-callback-function-is-not-called-for-spi-transactions-800-bytes-in-length

    不过、我们将对此进行研究。

    此致、

    亚瑟

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Arthur、您好!

    很好的酒店 是的、我认为这两个线程是同一个问题。  然而 ,我已经重新讨论了该线程和我当时所做的工作,并已确定我的结论,该线程一定是不正确的。

    我还没有像当时那样(根据.map 文件摘录和该线程跟踪捕获中的调试地址打印)将一个欠大的缓冲区传递给 SPI_TRANSFORT()。

    很抱歉给我带来了困惑、感谢您仔细研究这一问题。

    为了万一它是相关的,我使用:

    • SimpleLink SDK:  4.20.2.07
    • 编译器:  TIV20.2.7.LTS
    • XDCtools:  3.61.2.27_core

    从昨天的电子邮件,我也尝试过:

    • 传递一个不同的,足够大小的缓冲区,位于相当远的.bss 区域(远离 dmaSpi[01][RT]xControlTableEntry 内存),到 SPI_transfer()没有任何改进。
    • 将常规栈大小(在链接器脚本中)从1024字节增加到2048字节、没有改善。

    是否有某种 RTOS 后台任务定期清除未完成的 SPI 传输(或其他垃圾收集)? 我不相信我的代码是问题的,因为如果我不小心执行了 SPI_transferCancel(),我 仍然会 看到回调发生,我没有。

    TIA

    Sean。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Arthur、您好!

    我对双方都有一些好消息。 我已经解决了这个问题、完全属于我的故障- CC1310的工作方式与设计/预期完全相同。

    我只在任何给定的事务中使用 SPI 来发送或接收、不能同时使用 SPI (即全双工)。 到目前为止,SPI_Transaction 和 SPI_TRANSMIT()都没有任何字段来指示传输方向-它们的行为完全对称。 在本例中、我没有为 NULL 分配未使用的缓冲区指针(即 spi_Transaction.rxBuf)、因为我仅关注到另一个微控制器的 SPI Tx-ing 数据。 因此、CC1310从 SPI 总线"读取"到未制图的存储器空间、覆盖谁知道什么。

    设置 rxBuf = NULL 时、我现在可以执行 CC1310支持的完整1024字节传输。

    再次感谢您愿意进行调查。

    此致、

    Sean。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Sean、您好!

    我们非常感谢您提供的详尽反馈!

    我确实查看了驱动程序源、它确实是通过众多"检查提供的 Rx 缓冲区"调用进行解释的。 驱动程序本身实际上只是检查提供的指针是 NULL 还是其他任何内容。

    我们的驱动程序示例确保 rxBuf/txBufs 在不使用时被设置为 NULL、但没有说明为什么会这样。

    此致、

    亚瑟