[参考译文] CC3300：需要信息来验证引导、Wlan_Start 等的 MISO 功能和跟踪

您好 Shlomi Itzhak 

在实施过程中、您提供的意见对我们非常有帮助。

我们还分析了从您这边共享的波形。 这也有帮助。

我们现在开始通过 MOSI 获取数据。 我认为我们接近通过初始通信、从中开始通过 MISO 接收数据。  

现在、我们主要是尝试将我们的测试数据与您一方共享的数据进行匹配。

能否请您详细说明一下您的评论“事件主机的行为有所不同。 以 AM243 作为基准、我们使用边沿。“

我们对此有进一步的疑问 基准波形 、  “SimpleLink CC33xx 主机接口“白皮书、即 我们的测试结果

主题 1) 加厚 MAC_R9_init_roleUp_SCAN_CONNECT.Sal 分析

我们研究了“ThickMAC_R9_init_roleUp_SCAN_CONNECT.Sal"以及“以及附加文档中初始通信的摘要。

流程摘要：

• 在此过程中、与的通信由主机发起 FF FE 80 00 10 F2 73 复位和 IRQ 触发后
• 在该命令 MISO 变为低电平之后。
• 主机再发送两条命令–
  • 0x62、0x00、0xBF、0xFC
  • 0x00、0x00、0x00、0x00
• 在第三条命令 IRQ 变为低电平后。
• 主机从 CC3301 读取的数据如所示 0x03、0xFF、0xFF、0xFF 并进一步读取后续数据

我们的疑问：

• 已理解此命令“ FF FE 80 00 10 F2 73 英寸 由  “WLAN_START"的“的“bus_sendInitCommand"函“函数启动
• 为什么此命令之后 MISO 变为低电平。 它表示什么？
• 主机首先读取数据如所示 0x03、0xFF、0xFF、0xFF。 这是什么数据？ SDK 从何处开始首次读取？
•  e2e.ti.com/.../Queries-regarding-initial-communication.docx

主题 2)“SimpleLink CC33xx 主机接口“白皮书问题

我们的疑问：

• 白皮书提到了“对于 SPI 模式、发送了操作码为 0 (CMD0) 的单个 SDIO 命令、以将器件设置为 SPI 模式“；此外 、白皮书还讨论了更多的配置、例如 a) 小端字节序和大端字节序、b) 16 位和 32 位字长、c) 位混合
  • 此命令是否作为“bus_sendInitCommand"的“的一部分发送。 请确认

主题 3) 我们的测试结果

• 我们开始使用“WLAN_START"命令“命令进行测试
  • 与 TI 波形参考一样、我们观察到具有一些不同数据的 8 字节初始时钟
  • 8 字节之后、MISO 保持高电平
  • 另外 2) 来自主机[1) 0x62、0x00、0xBF、0xFC、2) 0x00 的命令 0x00、0x00、0x00) 未观察到。
  • 我们的硬件有电平转换器。 用于 CC3301 的 1.8 MOSI 信号具有锯齿形状。
• 我们的疑问
  • 我们观察到与 TI 端共享的波形略有不同。 它是否需要与 TI 端的波形匹配？
  • 在我们的案例 2 中、未观察到命令、 MISO 保持高电平 、没有通过 MISO 读取的数据。 不使用 2 个命令的原因可能是什么？ 这是因为 MISO 保持高电平吗？ MISO 会因锯齿状 MOSI 信号而保持高电平。 您过去是否遇到过任何其他客户的这一观察？

谢谢。。

您好、

关于您的查询：

1. 是、 “"</s>“ FF FE 80 00 10 F2 73 英寸   由 “bus_sendInitCommand"启动“启动
2. MISO 在低电平状态时似乎处于空闲状态、但我认为只要它按照 CPOL/CPH 的设置（即 0 和 0）运行、就无关紧要了。 发送的初始命令实际上是在芯片侧配置 SPI 接口、因此 MISO 中的翻转实际上表明它已配置
3. IRQ 将通过接收 0xBFFC 进行确认、进而使 IRQ 无效。 然后、字节将 MISO 线路推送到主机。 。  0x03、0xFF、0xFF、0xFF  您看到的只是 FIFO 中的任何内容、但没有意义。 由于芯片从主机获得 SPI 时钟、因此它会继续发送数据。 第一个有意义的数据是在所有 0xFF 之后、您在这里看到 0x55 系列
4. 至于白皮书、 bus_sendInitCommand 正在配置一切、但此时只有一个配置是相关的、因此我无法保证使用其他配置
5. 至于与 STM 的集成、我记得 STM 中的 CPOL/CPH 存在一些问题。 您能否查看我的以下两个线程、看看它是否有意义？
   1.  回复：cc3300：cc3300 数据记录 
   2.  回复：CC3351MOD：RAMBTL / conf 文件下载问题 

此致、

Shlomi

 Shlomi Itzhak 

感谢您的答复。

STM32 中的一个 WLAN SPI 查询、

a) 请在 WLAN SPI 上提供一些输入

b) 在调用 SPI_WriteSync 之前、我们是否需要处理函数 bus_sendInitCommand 中的任何内容？

查询初始命令：

 如前所述、在 bus_sendInitCommand 中、它通过 SPI 发送一些其他数据、而不是从您一方接收到的数据。

发送的  FF FE 80 00 10 F2 73 在函数“bus_sendInitCommand"中“中。 我们从您一侧的迹线中拾取这些数据。 使用该命令、MISO 线路按预期变为低电平、这建议您已完成 CC3301 配置、如您所述。 这对我们来说是好事。

我想知道我们在得到时使用了以下配置  FF FE 80 00 10 F2 73。 请确认

#define SPI_16_BIT_SUPPORT 0x1
#define SPI_FIXEDBUSY_EN 0x2
#define SPI_BIT_Swizzle 0x4
#define SPI_CS_BIT_CLEAN 0x8
#define SPI_DATA_POL_BIT_SET 0x10
#define SPI_SET_CLK_FREQ 0x20
#define SPI_ADD_1_CLK 0x40

在您的跟踪中、我们发现有 2 条命令是 主机在 MISO 变为低电平后再发送两条命令、

• • 0x62、0x00、0xBF、0xFC
  • 0x00、0x00、0x00、0x00
  • 我们未观察到这 2 个命令
  • 0xBFFC 确认中断并读取一些重要值、例如消息类型（命令完成，事件，数据）。
  • 什么是 0x62、0x00？
  • 从 0x62、0x00、0xBF、0xFC 的位置触发？

 您提到“  0x03、0xFF、0xFF、0xFF  您看到的只是 FIFO 中的任何内容、但没有意义。 由于芯片从主机获得 SPI 时钟、因此它会继续发送数据。 第一个有意义的数据是在所有 0xFF 之后、在这里您可以看到 0x55 系列“。  

主机启动的首次读取操作的表单  0x03、0xFF、0xFF、0xFF   0x55 系列的材料吗？

谢谢...

您好、

这是次序  FF FE 80 00 10 F2 73 应由器件收到、所以我认为您应该没问题。

至于配置、您介绍的只是定义、而不是实际配置。 介绍以下位：

• 32 位（A6 位未定义）
• 没有位混合
• 在 INIT CMD 之后添加 1 个 CLK
• CPH/CPOL 应使用默认值 0、0

您可以在代码中看到高 2 个字节的解释。

#define WSPI_CMD_READ 0x40000000
#define WSPI_CMD_WRITE 0x00000000
#define WSPI_CMD_FIXED 0x20000000
#define WSPI_CMD_BYTE_LENGTH 0x1FFE0000
#define WSPI_CMD_BYTE_LENGTH_OFFSET 17
#define WSPI_CMD_BYTE_ADDR 0x0001FFFF

下面的 17 个片段是地址、然后 12 位是长度。 然后是方向位。

• 0x6200 表示大小为 256 字节的读取操作

它是从 bus_sendReadCommand() 触发的、但有一些 SW 层从该命令的源端一直运行、该源 端位于 Fw Event_Sm－ReadIntrInfo() 中。

在您开始获取 0x55 之前、会生成 0xFF。

Shlomi