[参考译文] CC3301MOD：查询&quot；WLAN_START&quot；API 和 OSI_freertos.c

尊敬的 Yogesh：

1) 我们发现了文件处理方式 Wi-Fi 固件二进制文件、RAM 引导加载程序 。 我们开始了解“ Wi-Fi‑Wi-Fi 固件二进制文件是在 CC33xx Wi-Fi‑Wi-Fi 芯片内运行的内部操作系统 “。 请确认我们的理解。

FreeRTOS 是在 CC33xx 中运行的内部操作系统、但使用 OSI_freetros.c 等文件来初始化与 FreeRTOS 相关的各种设置。

2) 恰好是主机将 Wi-Fi 固件二进制文件、RAM 引导加载程序传输到 CC3301 的时间。 我们认为它是在“"之后“之后处理的 WLAN_START “函数调用。 SDK 源代码的哪个部分处理此功能。

处理此问题的主文件是 init_device.c、该文件是在 WLAN_START 期间调用的。

3) 移植时、我们在“osi_freertos.c"中“中注释了例程。 没有评论的例程将会发生什么。 CC3301 是否可以工作？ 我们在 bus_sendInitCommand MISO 变为低电平后找到。

您评论了哪些例程？ 为什么这些例程被注释掉？

4) 移植到 STM32F412ZG 时需要考虑的任何特殊点,请与我们分享。

我在这里什么都没想到。

在进行 WLAN_START 查询时、能否发送  所附逻辑分析仪图像的 Saleae 文件？ 这将使我更好地刮擦你看到的东西。

此致、

Josh Prushing

你好 Josh Prushing 

感谢您的答复。

我们进一步分析了“ OSI_FREERTOS.c“。 我们有如下几个问题。 还添加了“ WLAN_START“ 获取增益后提供相关查询、并添加了从 TI 端收到的跟踪。

我们理解了以下内容：“OSI_freertos.c"支持“支持“ramblr"→“→RAM 引导加载程序映像、“FW"→“→主固件映像、“cc33xx-conf"→“→设备配置 Blob、“our_sec"→“→BLE 本地安全数据等 作为“WLAN_START"功能“功能的一部分、“FW"和“和“ramblr"传输“传输到 CC3301 器件、如下所述。

主固件映像、 RAM 引导加载程序映像 作为 Wlan_Start 功能的一部分的传递、如下所示。

Wlan_Start — 它称为 InitHostDriver

         InitHostDriver — 它在下面调用

                             WLAN_IRQInitBeforeHwInit (void *) FwEvent_IRQ_HANDLER)；

                Bus_sendInitCommand（保留，0）；

                             INIT_DEVICE — 它在下面调用

                                                 RET = ctrlCmd Fw_Container 下载（“ramblr")“）；

                                                 RET = ctrlCmd Fw_Container 下载（“FW")“）；

                                                                     WLSendFWDownloadCommand

                                                                                         CMD_Send

我们还理解了各种例程的地址

#define FW_OFFSET_IN_FLASH (0x800000)

#define RAM_OFFSET_IN_FLASH (0x900000)

#define CC33XX_CONF_OFFSET_IN_FLASH (0xa00000)

define BLE_OUR_SEC_OFFSET_IN_FLASH (0xb00000)

#define BLE_PEER_SEC_OFFSET_IN_FLASH (0xb01000)

#define BLE_CCCD_OFFSET_IN_FLASH (0xb02000)

 

还在 SDK 中找到了各种二进制代码 cc33xx-conf.bin、cc33xx_fw.bin

 查询“osi_freertos.c"</s>“

 1) 其中的“ramblr"→“→RAM 引导加载程序映像、“FW"→“→主固件映像等存储在 AM243x 评估板上、由示例程序“CC3xx_thick_mac_network_terminal"使用“使用。 是在内部闪存还是外部闪存上？

2) 编程“ramblr"，“，"FW"、"FW"等“等的“的程序是什么 是否使用 cc33xx-conf.bin、cc33xx_fw.bin 进行编程？

3) 在“ramblr"，“，"FW"、"FW"，“，"cc33xx-conf"“"cc33xx-conf"，、，"our_sec"“"our_sec"，“，"peer_sec"、"peer_sec"中“中，“，</s>、 ““、“CCCD"，“，所有、所有这些都是 SDK 运行或未使用其中任何一个所必需的。 请提供详细信息。

 

 查询“WLAN_START"</s>“  

• 根据从您这边接收到的 init 波形、我们了解了随附的“WLAN_START"命令“命令初始序列的以下行为。
• 复位后、IRQ 变为高电平
• 1 — 第一个命令 FF FE 80 00 10 F2 73 作为“Bus_sendInitCommand"的“的一部分、MISO‘低电平。
• 2 - 0x62、0x00、0xBF、0xFC
• 3 - 0x00、0x00、0x00、0x00
• 在第三条命令 IRQ 变为低电平后。
• 4 — 主机从 CC3301 读取的数据为 0x03、0xFF、0xFF、0xFF
• 5 — 主机从 CC3301 读取的数据为 0x55
• 上述 2、3、4、5 不是“WLAN_START"函“函数的直接组成部分。

 我们的疑问：

• 我们理解序列 2 是 IRQ_Acknowledgement。 但 IRQ 触发很早。 您能确切说明触发了哪个事件序列 2 吗？ 请指定确切的代码参考。 在本例中、在集成 SDK 之后、我们观察了初始化序列 FF FE 80 00 10 F2 73、 但未观察到 IRQ_Acknowledgement。
• 同样、请告知序列 3、4、5 的确切代码基准

从 TI 收到的跟踪：

填充 MAC_5F00_R9_5F00_init_5F00_roleUp_5F00_scan_5F00_CONNECT.Sal

命令初始序列 ：

e2e.ti.com/.../0044.Wlan_5F00_start-initial-sequence.docx

谢谢。。

你好 Josh Prushing 

感谢您的答复。

我们进一步分析了“ OSI_FREERTOS.c“。 我们有如下几个问题。 还添加了“ WLAN_START“ 获取增益后提供相关查询、并添加了从 TI 端收到的跟踪。

我们理解了以下内容：“OSI_freertos.c"支持“支持“ramblr"→“→RAM 引导加载程序映像、“FW"→“→主固件映像、“cc33xx-conf"→“→设备配置 Blob、“our_sec"→“→BLE 本地安全数据等 作为“WLAN_START"功能“功能的一部分、“FW"和“和“ramblr"传输“传输到 CC3301 器件、如下所述。

主固件映像、 RAM 引导加载程序映像 作为 Wlan_Start 功能的一部分的传递、如下所示。

Wlan_Start — 它称为 InitHostDriver

         InitHostDriver — 它在下面调用

                             WLAN_IRQInitBeforeHwInit (void *) FwEvent_IRQ_HANDLER)；

                Bus_sendInitCommand（保留，0）；

                             INIT_DEVICE — 它在下面调用

                                                 RET = ctrlCmd Fw_Container 下载（“ramblr")“）；

                                                 RET = ctrlCmd Fw_Container 下载（“FW")“）；

                                                                     WLSendFWDownloadCommand

                                                                                         CMD_Send

我们还理解了各种例程的地址

#define FW_OFFSET_IN_FLASH (0x800000)

#define RAM_OFFSET_IN_FLASH (0x900000)

#define CC33XX_CONF_OFFSET_IN_FLASH (0xa00000)

define BLE_OUR_SEC_OFFSET_IN_FLASH (0xb00000)

#define BLE_PEER_SEC_OFFSET_IN_FLASH (0xb01000)

#define BLE_CCCD_OFFSET_IN_FLASH (0xb02000)

 

还在 SDK 中找到了各种二进制代码 cc33xx-conf.bin、cc33xx_fw.bin

 查询“osi_freertos.c"</s>“

 1) 其中的“ramblr"→“→RAM 引导加载程序映像、“FW"→“→主固件映像等存储在 AM243x 评估板上、由示例程序“CC3xx_thick_mac_network_terminal"使用“使用。 是在内部闪存还是外部闪存上？

2) 编程“ramblr"，“，"FW"、"FW"等“等的“的程序是什么 是否使用 cc33xx-conf.bin、cc33xx_fw.bin 进行编程？

3) 在“ramblr"，“，"FW"、"FW"，“，"cc33xx-conf"“"cc33xx-conf"，、，"our_sec"“"our_sec"，“，"peer_sec"、"peer_sec"中“中，“，</s>、 ““、“CCCD"，“，所有、所有这些都是 SDK 运行或未使用其中任何一个所必需的。 请提供详细信息。

 

 查询“WLAN_START"</s>“  

• 根据从您这边接收到的 init 波形、我们了解了随附的“WLAN_START"命令“命令初始序列的以下行为。
• 复位后、IRQ 变为高电平
• 1 — 第一个命令 FF FE 80 00 10 F2 73 作为“Bus_sendInitCommand"的“的一部分、MISO‘低电平。
• 2 - 0x62、0x00、0xBF、0xFC
• 3 - 0x00、0x00、0x00、0x00
• 在第三条命令 IRQ 变为低电平后。
• 4 — 主机从 CC3301 读取的数据为 0x03、0xFF、0xFF、0xFF
• 5 — 主机从 CC3301 读取的数据为 0x55
• 上述 2、3、4、5 不是“WLAN_START"函“函数的直接组成部分。

 我们的疑问：

• 我们理解序列 2 是 IRQ_Acknowledgement。 但 IRQ 触发很早。 您能确切说明触发了哪个事件序列 2 吗？ 请指定确切的代码参考。 在本例中、在集成 SDK 之后、我们观察了初始化序列 FF FE 80 00 10 F2 73、 但未观察到 IRQ_Acknowledgement。
• 同样、请告知序列 3、4、5 的确切代码基准

从 TI 收到的跟踪：

填充 MAC_5F00_R9_5F00_init_5F00_roleUp_5F00_scan_5F00_CONNECT.Sal

命令初始序列 ：

e2e.ti.com/.../0044.Wlan_5F00_start-initial-sequence.docx

谢谢。。

从 TI 端接收的跟踪链接如下所示

e2e.ti.com/.../ThickMAC_5F00_R9_5F00_init_5F00_roleUp_5F00_scan_5F00_connect.sal

尊敬的 Yogesh：

 1) 其中的“ramblr"→“→RAM 引导加载程序映像、“FW"→“→主固件映像等存储在 AM243x 评估板上、由示例程序“CC3xx_thick_mac_network_terminal"使用“使用。 无论是在内部闪存还是外部闪存上？

在 AM243x 上、示例程序存储在外部闪存中。

2) 编程“ramblr"，“，"FW"、"FW"等“等的“的过程是什么 是否使用 cc33xx-conf.bin (cc33xx_fw.bin) 进行编程？

Cc33xx_fw.bin 配置 CC33xx FW、cc33xx_2nd_loader.bin 配置 rambtl。 顺序（如果遵循我们的指南，我们的驱动程序将进行处理）是对 ospi 调试 ti image 进行编程->示例 appimage -> cc33xx_fw.bin -> cc33xx_2nd_loader.bin -> static_calibration.bin。 如需更多信息、请参阅  cc33xx_RTOS_MCU_PACKAGE_R8.1 SDK 中的文档。

3) 出自“ramblr"，“，"FW"、"FW"，“，"cc33xx-conf"“"cc33xx-conf"，、，"our_sec"“"our_sec"，“，"peer_sec"、"peer_sec"，“，</s>“ 、““、“CCCD"，“，所有、所有这些都是 SDK 运行或其中任何一个未使用所必需的。

“our_sec"，“，"peer_sec"、"peer_sec"和“和"CCCD"“"CCCD"与“与 BLE“ BLE 相关。 如果您的应用不使用 BLE 功能、则不需要这些功能。

需要“rambl"，“，"fw"、"fw"和“和"cc33xx-conf"“"cc33xx-conf"。“。</s>“  

我们理解序列 2 是 IRQ_Acknowledgement。 但 IRQ 触发很早。 您能确切说明触发了哪个事件序列 2 吗？ 请指定确切的代码参考。 在本例中、在集成 SDK 之后、我们观察了初始化序列 FF FE 80 00 10 F2 73、 但未观察到 IRQ_Acknowledgement。

我相信 Shlomi 已经在另一个线程中回答了这个问题:

• 0x62 0x00
  • “0x6200 表示大小为 256 字节的读取操作。 它是从 bus_sendReadCommand() 触发的、但有一些 SW 层从该命令的源端一直延伸到 Fw Event_Sm－ReadIntrInfo() 中。“
    
• 0xBF 0xFC
  • “IRQ 将通过接收 0xBFFC 进行确认、进而使 IRQ 无效。 然后、将字节推入 MISO 线路至主机。“

同样、请告知序列 3、4、5

的确切代码参考

我相信 Shlomi 已经在 另一个线程中回答了这个问题:

• 0x00 0x00 0x00 0x00 0x00
  • MISO 处于低电平状态、也就是说它处于空闲状态（无数据）：“MISO 在低电平状态时似乎处于空闲状态... 发送的初始命令实际上是在芯片侧配置 SPI 接口、因此 MISO 中的翻转实际上表明它已配置“
• 0x03 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
  • 。  0x03、0xFF、0xFF、0xFF  您看到的只是 FIFO 中的任何内容、但没有意义。 由于芯片从主机获得 SPI 时钟、因此它会继续发送数据。
• 0x55
  • 第一个有意义的数据是在所有 0xFF 之后、您在这里看到 0x55 系列

因此、序列 2-5 由 bus_sendReadCommand() 和 与此命令相关的其他 SW 层触发。 如果我误解了您的 WLAN_START 查询、请告诉我。

此致、

Josh Prushing

你好 Josh Prushing 

现在、我们能够对 CC3301 执行初始序列测试。 我们看到了  FF FE 80 00 10 F2 73、后跟 IRQ ACK、“0x03 0xFF 0xFF“和 0x55 系列数据。

现在、我们将  在内部闪存或外部闪存中实现“rambl"，“，"FW"、"FW"和“和"cc33xx-conf"“"cc33xx-conf"编“编程“程。  

我们有几个问题：

• 我们需要有关“ramblr"→“→RAM 引导加载程序映像、“FW"→“→主固件映像的信息。 从主机“bus_sendInitCommand"之后“之后、主机进一步传输“ctrlCmd Fw_Container（“ramblr")“）“和“ctrlCmd Fw_Container Download（“FW")“）“。 CC3301 如何使用“RAM 引导加载程序映像“和“主固件映像“、以及“主固件映像“的执行方式。

 

• “cc33xx-conf"对“对 CC3301 的用途是什么？

 

• 每个文件都有不同的起始地址

#define FW_OFFSET_IN_FLASH (0x800000)

#define RAM_OFFSET_IN_FLASH (0x900000)

#define CC33XX_CONF_OFFSET_IN_FLASH (0xa00000)

define BLE_OUR_SEC_OFFSET_IN_FLASH (0xb00000)

#define BLE_PEER_SEC_OFFSET_IN_FLASH (0xb01000)

#define BLE_CCCD_OFFSET_IN_FLASH (0xb02000)

能否说明“rambl"，“，"fw"、"fw"和“和"cc33xx-conf"“"cc33xx-conf"所“所需“需的最大大小是多少？

• Form Host 是否需要 在 SDK 中处理的每次启动时发送 rambl“、“FW"和“和“cc33xx-conf"？“？ 或者 CC3301 将这些文件存储在其内部闪存中？
•  从工厂收到的用于 rambl“、“FW"和“和“cc33xx-conf"的“的 Fresh CC3301 的状态是什么。 是空白的还是已使用最新版本预编程？
•  在我们的应用中、使用 TI 提供的基于的 Python 脚本对 rambl“、“fw"和“和“cc33xx-conf"进行“进行编程  STM32F412ZG
  • 了解 TI 评估板的编程知识
    • 首先将 TI 评估板置于 UART 引导模式
    • 使用.bin 文件运行 python 脚本
    • Python 脚本将通过串行方式发送.bin 文件数据
    • TI 评估板代码将接收此数据并存储到外部闪存中
    • 请确认我们的理解。 任何缺失的点都表明了这一点。
  • 是否可以在  STM32F412ZG 上使用相同的 python 脚本? 如果可能、请建议我们如何将相同内容整合到应用中。

谢谢...

尊敬的 Yogesh：

CC3301 如何使用“RAM 引导加载程序映像“和“主固件映像“、以及如何执行“主固件映像“。

刷写主机 MCU 后、RAM 引导加载程序映像和主固件映像会在每次复位时在 CC3301 上执行。 RAM 引导加载程序映像初始化 CC33xx、而主固件映像用于 CC33xx 功能。 这些命令在 WLAN_START 期间调用、允许用户使用 CC33xx 的 Wi-Fi 和 BLE 功能。

] CC3301 的“cc33xx-conf"用途“用途是什么？

该文件包含参数列表并分配默认值。 这是无线模块正常运行所必需的。  

您能告诉“rambl"，“，"FW"、"FW"和“和"cc33xx-conf"“"cc33xx-conf"的“的最大“最大大小是多少吗？

这些内容的最大大小尚未确定（因为新的 SDK 版本中添加了功能）、这些地址只是我们为 AM243 闪存存储这些文件的位置。 如果 ST 主机具有相同的闪存大小、您可以重复使用这些地址、而不会出现任何问题、但如果 ST 主机的闪存大小较小 、您可能需要重新访问这些地址存储在应用中的位置。  

表单主机是否需要 在每次启动时按照 SDK 中的处理方式发送 rambl“、“FW"和“和“cc33xx-conf"？“？ 或者 CC3301 将这些文件存储在其内部闪存中？

在运行 WLAN_START 时从主机到 CC3301、每次复位都会调用该位。 CC3301 基于 SRAM、因此在复位时擦除这些内容。

主机 MCU 应将其存储在闪存上、因此每次要运行程序时、不必写入主机 MCU、但如果复位了 CC33xx、则需要通过运行 WLAN_START 重新初始化。

 从工厂收到的 fresh CC3301 的状态是什么 、分别是 rambl“、“FW"和“和“cc33xx-conf"。“。 是空白还是使用最新版本预编程？

该字段将为空白、因为这是基于 SRAM 的器件 — 因此，每次重新启动/上电时、CC33xx 都会清除 RAM。

] 使用 TI 在我们的应用程序中提供的基于的 python 脚本对 rambl“、“FW"和“和“cc33xx-conf"进行“进行编程  STM32F412ZG

• 了解 TI 评估板的编程知识
  • 首先将 TI 评估板置于 UART 引导模式
  • 使用.bin 文件运行 python 脚本
  • Python 脚本将通过串行方式发送.bin 文件数据
  • TI 评估板代码将接收此数据并存储到外部闪存中
  • 请确认我们的理解。 任何缺失的点都表明了这一点。
• 是否可以在  STM32F412ZG 上使用相同的 python 脚本? 如果可能、请建议我们如何将相同内容整合到应用中。

[/报价]

ST 主机在刷写 appimage 和.bin 文件的方式上将有一些差异。 应该有一些软件/调试器、您可以使用它们将这些文件（以及主机 MCU 所需的任何其他文件）刷写到您的器件中、并能够与 CC33xx 配合使用。

由于这是 AM243 特有的、因此无法使用相同的 python 脚本、但刷写.bin/appimage 文件的基本过程应该相对相似、我想 ST 提供了一个工具来执行此操作（在线快速搜索指示   STM32CubeProgrammer 可能是一个不错的起点）。

如果您有任何其他问题、请告诉我！

此致、

Josh Prushing

您好、Josh、

感谢您的详细输入。

几个查询。

1) 需要一个确认。 您的所有输入均适用于 CC3300 MOD 以及 CC3300。 请确认。

CC3300 MOD 是 CC3300 IC + 天线+ 40MHz 晶体、如方框图中所述。 无外部闪存。

2) 出于好奇心、再需要一个信息、如果  CC3300 MOD 在启动期间为空、则它如何从主机响应“bus_sendInitCommand"，“，并、并在发现接收到的配置正确后将 MISO 线拉至低电平。

3) 在内部讨论时、我们遇到了一些关于从 Wi-Fi 合规性证书的外部闪存角度存储 CC3300 MOD 程序的问题。

a) TI SDK 是否在将这些二进制文件发送到 CC3300 之前正在检查这些二进制文件的完整性。  在对 CC3300 进行编程之前、Wi-Fi 合规性角度是否要求检查二进制文件的完整性？

b) 是否有办法检查引导加载程序、固件和配置的版本？  从 Wi-Fi 合规性 的角度来看、是否要求检查固件版本或在认证相关文档中提及相同版本。

c) 我们需要考虑 Wi-Fi 合规性观点的任何其他要点、请与我们分享。

4) 我们了解 CC3300 MOD 认证针对“CE、FCC、ISED、MIC、Wi-Fi 认证芯片“的要求。 您能与我们分享这些证书详细信息吗？ 我们想与 Wi_Fi 认证机构分享。

谢谢。。

尊敬的 Yogesh：

1) 需要一个确认。 您的所有输入均适用于 CC3300 MOD 以及 CC3300。 请确认。

是、在软件方面、这些器件是相同的。

2) 为了满足好奇心、再需要一个信息 、如果 CC3300 MOD 在启动期间为空、则它如何从主机响应“bus_sendInitCommand"，“，并、并在发现接收到的配置正确后将 MISO 线拉至低电平。

这是因为 CC33xx 的 ROM 中存储了在初始化完成期间通过 WLAN_START 调用的信息。

[引述 userid=“496917" url="“ url="~“~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1633965/cc3301mod-queries-for-wlan_start-api-and-osi_freertos-c/6308937

3) 在内部讨论时、我们遇到了一些关于从 Wi-Fi 合规性证书的外部闪存角度存储 CC3300 MOD 程序的问题。

a) TI SDK 是否在将这些二进制文件发送到 CC3300 之前正在检查这些二进制文件的完整性。  在对 CC3300 进行编程之前、Wi-Fi 合规性角度是否要求检查二进制文件的完整性？

b) 是否有办法检查引导加载程序、固件和配置的版本？  从 Wi-Fi 合规性 的角度来看、是否要求检查固件版本或在认证相关文档中提及相同版本。

c) 我们需要考虑 Wi-Fi 合规性观点的任何其他要点、请与我们分享。

4) 我们了解 CC3300 MOD 认证针对“CE、FCC、ISED、MIC、Wi-Fi 认证芯片“的要求。 您能与我们分享这些证书详细信息吗？ 我们想与 Wi_Fi 认证机构分享。

[/报价]

使用 RTOS MCU 主机的 CC33xx / CC33xxMOD 未经过 Wi-Fi 认证。 在Wi-Fi Alliance 产品查找器上、可以看到支持的 Wi-Fi 组件操作系统是 CC330x 的 Linux 主机。 这意味着、如果您尝试满足 Wi-Fi 合规性要求、将无法使用 RTOS SDK + MCU 主机、则需要将 Linux 主机与 CC33xx 和 Linux SDK 配合使用。

值得注意的是、我们有一项称为安全启动的安全功能、可在启动时验证数字签名。 这意味着在启动时会检查固件的完整性和真实性。 这不是 WFA 认证要求、而只是我们器件的一个功能。

如果您希望从应用程序读取固件版本、还应该有一种方法。 网络终端示例有一个具有此功能的命令、您可以将其重新用于应用程序。

有关我们的其他监管认证、您可以在此处申请了解详情。 只要您使用了正确的 conf 文件、这些命令就对 RTOS MCU 主机有效。  

您的应用是否需要 RTOS MCU 主机、或者是否可以用其代替 Linux 主机、以满足您的 Wi-Fi 认证要求？ 您能解释一下为什么这里需要 WFA 认证吗？

此致、

Josh Prushing

您好、Josh、

我们现有的开发基于  STM32F412ZG、 带 wice-SDK-6.6.1 SDK、AP6212 Wi-Fi 4 模块、 Broadcom BCM4343 芯片组。

它已通过如下认证。

为确保我们的产品 Wi-Fi 6 合规性、我们选择了使用 SDK “cc33xx_RTOS_MCU_PACKAGE_R8.1"的“的 TI CC3300 MOD。

修改了电流后、硬件已经准备就绪 STM32F412ZG  支持能力  CC3300 模块  并致力于软件。

因此、我们的应用需要  RTOS MCU 主机、不能替代 Linux 主机。

因此、请提出我们的新开发将面临的挑战、以及我们需要遵循的方法是什么。

谢谢。。

尊敬的 Yogesh：

我们将 在今年下半年开始在具有 RTOS SDK 的 CC3300MOD 上进行 Wi-Fi 认证、但预计这将需要 相当长的时间、因此我不确定此认证何时完成。

由于需要经过 Wi-Fi 认证的器件、我们的建议是改用CC35xx。  该器件可以在没有 ST 主机的情况下运行、也可以配置为从 ST 主机读取命令。

如果您对此有任何其他问题、敬请告知。

此致、

Josh Prushing

你好 Josh Prushing 

感谢您的详细信息。

在您的意见之后、我介绍了各种详细信息。

关于认证流程了解“产品的 Wi-Fi 认证可以通过获得 导数 、 QuickTrack 或 FlexTrack 路径“

导数 -当最终产品使用已经过认证的 Wi‑Fi 解决方案 ( 符合要求的解决方案） 与‑一样、没有任何变化。

 ‑、我在 https://www.wi-fi.org/product-finder 上查看了经过认证的 Wi-Fi 解决方案 、并找到了 CC330x (Wi-Fi 组件操作系统、被称为 Linux)。

另外、还检查了  称为 RTOS 的 CC335X Wi-Fi 组件操作系统

我们的疑问：

1) 因此、使用具有“cc33xx_RTOS_MCU_PACKAGE_R8.1" SDK“ SDK 的 CC3300MOD 时、我们无法实现  衍生产品或 QuickTrack。 对吧？  

2) 去  FlexTrack  这是另一种选择。 但我想这将需要更多的时间和认证费用也很高。 我们决定去看看  FlexTrack、  那么一些测试是否可能无法正常工作并需要在 SDK 中进行更新？

3) 我们已经开始在 STM32 上移植 CC330x SDK “cc33xx_RTOS_MCU_PACKAGE_R8.1"。“。 我们了解了这个基于 FreeRTOS 版本 10.4.3 的 SDK。

   a) 那么“CC335X SDK“和“cc33xx_RTOS_MCU_PACKAGE_R8.1"之间“之间的架构差异是什么。  

   b) “CC335X SDK“中的自由 RTOS 版本是什么

   c) 我们预见到 “CC335X SDK“对 “cc33xx_RTOS_MCU_PACKAGE_R8.1"存在“存在的任何挑战

4) CC3300 MOD 和 CC335X MOD 是否引脚和工作条件（电压，频率等）兼容、无需更改硬件。 PLZ 确认。

5) 我们检查“对于我们的其他监管认证,你可以 在这里要求更多的信息。“ 我们找到了 CC3301 MOD 的证书。 CC3300 MOD 没有可用的报告。 我们知道 CC3301 MOD 的报告适用于 CC3300 MOD。 请确认。

  谢谢。。

你好 Josh Prushing 

感谢您的详细信息。

在您的意见之后、我介绍了各种详细信息。

关于认证流程了解“产品的 Wi-Fi 认证可以通过获得 导数 、 QuickTrack 或 FlexTrack 路径“

导数 -当最终产品使用已经过认证的 Wi‑Fi 解决方案 ( 符合要求的解决方案） 与‑一样、没有任何变化。

 ‑、我在 https://www.wi-fi.org/product-finder 上查看了经过认证的 Wi-Fi 解决方案 、并找到了 CC330x (Wi-Fi 组件操作系统、被称为 Linux)。

另外、还检查了  称为 RTOS 的 CC335X Wi-Fi 组件操作系统

我们的疑问：

1) 因此、使用具有“cc33xx_RTOS_MCU_PACKAGE_R8.1" SDK“ SDK 的 CC3300MOD 时、我们无法实现  衍生产品或 QuickTrack。 对吧？  

2) 去  FlexTrack  这是另一种选择。 但我想这将需要更多的时间和认证费用也很高。 我们决定去看看  FlexTrack、  那么一些测试是否可能无法正常工作并需要在 SDK 中进行更新？

3) 我们已经开始在 STM32 上移植 CC330x SDK “cc33xx_RTOS_MCU_PACKAGE_R8.1"。“。 我们了解了这个基于 FreeRTOS 版本 10.4.3 的 SDK。

   a) 那么“CC335X SDK“和“cc33xx_RTOS_MCU_PACKAGE_R8.1"之间“之间的架构差异是什么。  

   b) “CC335X SDK“中的自由 RTOS 版本是什么

   c) 我们预见到 “CC335X SDK“对 “cc33xx_RTOS_MCU_PACKAGE_R8.1"存在“存在的任何挑战

4) CC3300 MOD 和 CC335X MOD 是否引脚和工作条件（电压，频率等）兼容、无需更改硬件。 PLZ 确认。

5) 我们检查“对于我们的其他监管认证,你可以 在这里要求更多的信息。“ 我们找到了 CC3301 MOD 的证书。 CC3300 MOD 没有可用的报告。 我们知道 CC3301 MOD 的报告适用于 CC3300 MOD。 请确认。

  谢谢。。

你好 Josh Prushing 

请回复我们之前的帖子问题。

我有一个查询  认证解决方案  成本。

配置该转换器  认证解决方案  从 TI 假设 是 CC3350MOD 并将 SDK 移植到 STM32、并将“WiFi_ADAPTICATION_LAYER"修改“修改为与 STM32 兼容。 经过测试的应用。 在这种情况下、我们是否有资格“ Wi-Fi Alliance Path 的衍生产品 “并将获得 Wi-Fi 联盟证书、而无需测试工具测试。  

如果答案是肯定的,那么在上述情况下,我们需要去做  QuickTrack 和 FlexTrack。

谢谢...

尊敬的 Yogesh：

此处要求提供的某些信息较为敏感、不适合通过 e2e 论坛进行讨论。 我们将通过电子邮件与您联系以讨论此问题、并提供相关信息/解决方案。

有关您的技术问题的一些答案、请参阅以下内容：

4) CC3300 MOD 和 CC335X MOD 是否 引脚和工作条件（电压，频率等）兼容、并且无需更改硬件。 PLZ 确认。

是的、这些器件在引脚排列和运行条件下兼容。

5) 我们检查了“对于我们的其他监管认证、您可以 在此处申请更多信息。“ 我们找到了 CC3301 MOD 的证书。 CC3300 MOD 没有可用的报告。 我们知道 CC3301 MOD 的报告适用于 CC3300 MOD。 请确认。

是的、正确。

由于我们正在使该线程脱机、因此我将关闭该线程。

此致、

Josh Prushing