• 状态 Resolved
  • 已锁定 已锁定
  • 回复 7 回复
  • 订户 0 订户
  • 视图 632 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] CC3120：TCP 套接字 recv()数据正常，但 SENS()数据不正确

admin
Guru**** 2538950 points
Other Parts Discussed in Thread: CC3120

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/946829/cc3120-tcp-socket-recv-data-ok-but-send-data-incorrect

器件型号：CC3120

各位专家、您好！

我仍在为 CC3120构建自己的 lite 驱动程序(而不是使用 TI SDK)。 到目前为止、HTTP 部分已经完成并正常工作。 然后、我开始设计插座驱动器。 MCU 通过 UART 接口与 CC3120通信。 发送/接收到/接收到 CC3120的命令/响应运行良好。

CC3120是 AP 角色。 MCU 创建 TCP 服务器套接字、绑定地址、然后通过向 CC3120发送命令来侦听客户端连接。

macOS 是 STA 角色。 macOS 连接到 CC3120后会执行一个非常简单的 TCP 客户端程序。  

服务器接受客户端后、客户端(macOS)将向服务器发送/接收数据。 服务器(MCU)还将通过每500ms 发送一次命令 CC3120来向客户端发送/接收数据。 对于 recv()操作，可以正确接收来自 CC3120的异步数据。 但是对于 send()操作，客户端可以接收正确的数据大小(24字节)，但数据内容不正确。 以下是客户端 recv()数据日志(十六进制)： 

buf[24]：E0 43 00 20 00 00 00 00 00 00 00 00 A4 18 00 18 00 01 00 14 00 01 08
buf[24]：E0 43 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 01 00 14 00 01 08
buf[24]：E0 43 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 01 00 17 00 00 00
buf[24]：E0 43 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 01 00 14 00 01 08
buf[24]：E0 43 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 01 00 17 00 00 00
buf[24]：E0 43 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 01 00 14 00 01 08
buf[24]：E0 43 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 01 00 14 00 01 08
buf[24]：E0 43 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 01 00 14 00 01 08
buf[24]：E0 43 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 01 00 14 00 01 08
buf[24]：E0 43 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 01 00 14 00 01 08
buf[24]：E0 43 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 01 00 14 00 01 08
buf[24]：E0 43 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 01 00 14 00 01 08
buf[24]：E0 43 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 01 00 14 00 01 08

从数据日志中、我可以看出"18 00 01 00"是"Tx 命令描述"。 不适合他人。 我已经用不同的模式(例如全0、全1、0、1、2...23)预先填充了数据(在发送之前)、但结果是相同的。

  • STATUSR LUEN=24 (即18 00)
  • SD = 01
  • FamilyAndFlags = 00

为什么数据中显示 Tx 命令说明？ 显然、错误数据必须由 CC3120而不是客户端程序 (macOS)引起。

有什么想法吗？

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

    您好！

    您将缓冲器准确转储在何处？

    您提到问题出现在发送中、但记录在 Recv？

    您可能会在接口上不同步 、因此第2次发送会覆盖上一次发送的有效载荷、因此您会看到第2个命令标头作为有效载荷的一部分。

    您为何决定更换 SDK 的驱动程序？ 它可能为您节省了许多这样的问题。

    BR、

    Kobi

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

    您好、Kobi、

    问题出在服务器的 send()中，日志是在客户端的 recv()中记录的。

    问题每次都会发生。 即使我让它只执行一个传输、也会发生这种情况。 如果接口不同步、则 CC3120应该会获得一个无法识别的命令(操作码+ TX 说明)。 然后、客户端应该不能接收任何数据。 但客户端会得到相同的数据计数。 因此、CC3120确实会从 MCU 获取正确的命令并向客户端发送数据。  

    为什么我决定更换 SDK 的驱动程序？ 这是一个好问题。 20多年来、我一直在使用 TI SoC。 TI 在 IC 市场上非常成功、但软件始终是弱点。 我必须说、TI 是一家硬件公司、而不是一家软件公司。 CC3120和 MCU 之间的接口应该非常简单。 但是、如果您看一下 SDK 源代码、您会觉得它非常复杂、难以理解。

    对我来说、清晰有序的软件结构是首要任务。 因为我为客户设计产品、如果客户遇到问题、我必须尽快找出问题所在。 一个好的软件应该易于理解和维护。 即使在几年后、如果您查看源代码片段、您也应该立即了解该流程。 这就是为什么我通常可以在几分钟内而不是几小时或几天内解决问题的原因。

    无论如何 ，我不想在公开论坛上谈论太多这个问题。 如果您想讨论更多详细信息、可以向我发送私人邮件。

    该 SDK 适用于没有时间(或无法)构建更好的 SDK 的用户。 对我来说、我更喜欢构建一个新的。 但它确实需要时间、并且会遇到很多问题。

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

    由于 SDK 驱动程序可能不会出现此问题、因此我建议您监听 UART、并查看此简单用例中 SDK 驱动程序与您的驱动程序之间的区别。 您的命令结构可能有问题。

    BR、

    Kobi

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

    您好、Kobi、

    这是监听 UART 并在 SDK 驱动程序和我的驱动程序之间进行比较的最后一步、因为这需要时间。

    在此之前、我记录了发送到 CC3120的所有 MCU UART TX 数据。 以下是日志的 A 部分： 

    txMsg()同步：FF ee dd bb 21 43 34 12
txMsg()插头：0A 94 04 00
txMsg() TxDesc: 14 00 02 08
txMsg()同步：FF ee bb 21 43 34 12 loadMsg()
插头：0C 94 00 txMsg() Tx1c:
18 00 02 00 txMsg() Txadd: TxDesc
00 01 02 03 04 05 06 07 08 09 0A 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17

    第1行至第3行来自 recv()。 第4行至第7行来自 SENT()。 recv()和 send()都调用函数 txMsg()。 因此，日志打印在 txMsg()内部。 我可以看到、已发送命令和数据没有问题。 我们知道 TI 不会为每条命令提供详细的编程指南。 因此、我参考 SDK 源代码来了解如何发送命令、参数和数据。

    在我首次实施 HTTP 请求的驱动程序时。 不管怎样、所有 HTTP 请求都不会转发到 MCU。 我花了很多时间来比较 SDK 驱动程序和我的驱动程序之间的 TX/RX 数据。 没有什么不好的！ 直到添加了获取器件版本的命令、我才感到非常沮丧。 猜猜猜、MCU 收到了 HTTP 请求。 然后、我删除了该命令。 MUC 没有 HTTP 请求。

    什么是地狱？ HTTP 请求问题与完全不相关的命令有关？

    此时、我知道在实施其他功能时、我将来会遇到这种问题... 例如 socket.send ()问题。

    如果您有 RESTful 项目、并且您从 SDK 复制示例代码以设计您的项目、则该项目将在开始时工作。 但是、有一天、它将不再起作用、这仅仅是因为您没有足够的闪存、并决定删除无用的 Get-version 命令。

    这可能也会回答您的部分问题： 为什么我决定更换 SDK 的驱动程序？

    TI 是一家很好的公司、但它是一家硬件公司、而不是一家软件公司。 软件质量还不够好。

    到目前为止，我认为我的驱动程序没有任何错误会导致 send()问题。 如果 TI 的任何人可以帮助我检查上述日志并告诉我数据模式是正确的、则问题同样应该与另一个不相关的命令相关。

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

    您好、Robert、

    发送和接收的 TX 转储看起来正确。 我不确定问题是什么(可在中断/RX 侧找到)

    遗憾的是、我们只能支持主机驱动程序接口。  

    如前所述、您可以使用 SimpleLink 驱动程序作为开发自己的驱动程序的参考、但我们不建议这样做。

    如果您对 SimpleLink 驱动程序有任何问题、我们很乐意为您提供帮助。

    BR、

    Kobi

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

    您好、Kobi、

    非常感谢您的确认。

    SDK 示例代码运行良好、因此问题必须与我的驱动程序中的流程/计时有关。 我认为我现在最好停止追查这一问题。 我想首先实现其他功能、然后回到这个问题。 也许... 有机会... 我将遇到其他奇怪的问题、并最终找到解决此问题的方法。

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

    好的。

    BR、

    Kobi