[参考译文] CC3235MODASF：从 LaunchPad 迁移到嵌入式处理器失败

我们已经尝试过这一点。  我在应用中添加了一行代码、该代码提升了我们公开但当前未使用的 GPIO 引脚。  当我加载时、它不会升高。  当我收到朋友的响应时、我将发送.hex 和.dump 文件(我记得、发送私人邮件需要执行此操作)。

我们已经尝试过这一点。  我在应用中添加了一行代码、该代码提升了我们公开但当前未使用的 GPIO 引脚。  当我加载时、它不会升高。  当我收到朋友的响应时、我将发送.hex 和.dump 文件(我记得、发送私人邮件需要执行此操作)。

尝试下载您提供的内容后、Wifi 模块似乎被欺骗。  我甚至无法将我们正在工作的 WiFi 应用程序恢复到它。  我甚至尝试了恢复出厂设置、但没有帮助。

您好、Wayne、

嗯。 这不是很好、也不是我们所期望的。 作为还原尝试的一部分、您是否尝试了完整的闪存格式？

今天、我将回顾您通过 DM 发送的信息、并努力提供一些其他建议。

此致、

本·M

是的、我进行了恢复出厂设置。  我将 SOP 设置为000并进行了 POR。  POR (在文档 IMHO 中定义错误)是指实际断电、还是只是切换复位引脚？

 在我们的系统上设置 SOP 可能会有点问题、因为它由我们的主机芯片控制、然后实际上只有2个引脚暴露在外。  我有一个 ECO 修复请求。

一个问题是、Launchpad (至少是我的 LaunchPad)具有用于 SPI 编程的钉子连接器端口。  这似乎与我们的 J-Link 编程器/调试器使用的引脚不同。  是否有能够/应该能够做到这一点的参考规格？  我不知道的不同 J-Tag 盒或 J-Link 电缆？

您好、Wayne、

POR 应该只是复位引脚的切换。 下面、您是否只是指我们希望在这里工作的特定电缆？ 如果是、我可以通过使用我们的 Cheetah 编程器提供图片。

现在、我能够通过这个主题寻找线索、还有几个问题-

• 您希望在哪个 UART 实例中看到终端打印输出？ (UART0或 UART1)
• 您是否一直在开发模式下构建新映像(基于 SDK 中的 at_commands 示例)？
• 您能否共享相同的.hex 文件和.dump、而是共享重新编程后成功运行的映像？

此致、

本·M

此外、我还看到在线程开始时对 UART0引脚进行了一些混淆。 在模块封装上、您可以看到引脚46/47。 在模块内部、这些映射到 CC3235 IC 上的引脚55/57。  

这些也是引导加载程序用于 UART 编程的引脚。 如果您设置了用于 UART 编程的 SOP 模式(100)、您应该能够通过 UART 对电路板上的模块进行编程。 您只需使用跳线将 LaunchPad 上的 XDS110上的 UART 引脚连接到模块上的这些引脚、或使用 FTDI 线缆之类的器件即可。

不是这需要成为解决方案、而是一个备份想法、用于尝试确保新映像正常、或者在通过 SPI 格式化后似乎无法恢复时、可能用于对器件进行格式化。

最棒的

本·M

我们使用了 stock at_command、但进行了一些微小的更改。  它被编程为使用 UART0 AFAIK：

您好、Wayne、

您是否能够将设备恢复为原始工作映像？

正确的做法是、at_commands 示例使用引脚55/57来表示 UART、该引脚映射到原理图中标记过的 UART0。 没关系。

从您发送的图像中可以看到、提供的原始文件(我认为这些文件基于 at_commands 示例)比似乎包含您的实际应用程序的文件大得多。 这很奇怪。

还有几个尝试的想法：

1) 1)我看到您在硬件上细分了 CC3235 NWP LOG 引脚。 您能否启用此输出以收集 at_commands 示例( 程序员指南第20节中的说明)中的 NWP 日志、并尝试再次运行它？ 将引脚连接到 UART 转 USB 转换器、查看是否可以使用串行终端记录输出。 让我们看看在应用程序尝试运行时是否得到任何结果。

2) 2)您是否尝试过通过 UART 接口进行编程、以查看通过编程方式加载和运行的 at_commands 示例？

此致、

本·M

被“欺骗”的设备已被新卡更换。

不确定文件大得多意味着什么。  我展示了工作模块的.hex 文件、工作模块为741k、新的故障模块为719k。  

我上次查看时、NWP LOG 引脚没有输出任何内容。  我将使用 UART0和 NWP 连接器填充新卡。  

我们无法对该 wifi 芯片进行编程的部分原因是我们的“主机”CPU 通过硬连线连接到 UART0引脚。  我们的主机软件无法进行下载。  为了使用 LaunchPad (或 FTDI)进行编程，需要一些硬件和软件工作，而且由于我们不能在生产中进行 UART 编程，因此这不是一个解决方案，而只是一个诊断。

您是否能够加载/诊断我们在您的设备上发送的图像？

从文档中、我看到启用 NWP 日志需要代码：
//如果您的应用已经配置了 UART0，则不需要此行
MAP_PRCMPeripheralClkEnable (PRCM_UARTA0、PRCM_RUN_MODE_CLK)；
//多路复用器引脚62至模式1以输出 NWP 日志
MAP_PinTypeUART (PIN_62、PIN_MODE_1)；

不确定这是什么。  此代码是否应该出现在 wifi 图像中？  

例如、我已经尝试过通过 SYSCFG 和软件设置 GPIO 引脚之一。  这两种方法似乎都适用于 LaunchPad 卡、但不适用于我们的嵌入式卡。

我正在尝试通过 UART 加载映像、方法是禁用主机并将 Launchpad 卡与嵌入式芯片的 UART 引脚交叉连接。  此时、由于此配置中的主机强制 SOP 为000、因此未成功。  寻找将其强制转换为010的方法。

我尝试升级到 CCS12、Uniflash8、SysConfig 1.13、然后使用 SPI 进行编程、但编写完后、WiFi 芯片中仍然没有生命体征。

也许我应该重新配置到较旧版本的 CCS/Uniflash？

您好、Wayne、

我刚刚被分配了这个线程。 让我用1-2天的时间来对其进行调整、下周我将与您再次进行讨论。

只是为了清除状态... 您是否能够运行您在器件上编写的任何代码？ 即使是一个简单的 GPIO 切换示例(不将 GPIO 切换添加到您的 AT 命令示例中、只是一个访问1/2 GPIO 的简单程序。 您可以将 简单代码基于 drivers/gpiointerrupt 示例)？

在哪里可以通过 CCS 调试器(即通过 JTAG)加载它？ 使用 Uniflash Over UART 将其编程到闪存？ 使用外部 SPI 编程器(使用 hex 文件)将其直接编程到闪存中？

您将需要添加用于将 PIN_62设置到 NWP 调试 UART 的代码。

启用  NWP (即在 sl_Start()调用之后)后，可以将这些行添加到您的应用程序代码中，并且调试数据将显示在 PIN_62上。 在 gpiointerrupt 示例中、由于未使用 NWP、因此预计不会输出)。

我们的旧 Wifi 图像工作正常、它是任何未加载的新模块。  我尝试使用 SysConfig 设置更改我们的新映像以将暴露的 GPIO 引脚设置为高电平或低电平、但这似乎不起作用。  我还尝试通过编程方式设置它们、但也不起作用。  我们生成的新程序映像看起来根本不运行。  

我们的自定义卡未填充 J 标签、仅填充 SPI。  我将与我们的硬件人员联系、了解添加连接器的难度。  

我刚刚尝试通过将自定义卡 Wifi 与 LaunchPad"host"交叉连接来对其进行编程。  尽管我可以看到 nRST 和中断被发送到 CC3235、但它从不响应中断。  我已验证我们将 SOP 设置为010和100 (均支持 UARTLOAD)、但没有乐趣。  我还尝试过重置为出厂映像、但这也不起作用。

我的最佳猜测是 nRst 线路不在电压规格范围内。  我们有一个带有主机复位信号的二极管 OR、因此这可能会影响工作。

由于我们看不到对 GPIO 测试的任何影响、因此我确实怀疑应用程序是否正在运行。

我认为这个问题是两种可能性之一。  1)我们的构建过程中的某个操作会导致错误的加载映像、甚至不会加载映像；2) CCS 和/或 Uniflash 中发生了更改、正在生成错误的加载映像。  

我已经回顾了我们的文档、并认为我们的流程与2年前构建良好负载映像时的流程相同。  我们缺少的工具是否添加了一些步骤？  您能否确认当前 CCS/Uniflash 可以生成可行的.hex 文件以使用 SPI 加载。  我注意到一些 LaunchPad 卡甚至没有安装 SPI 连接器、是否已弃用此功能？

一个想法是使用我们新收购的 XDS110对 CC3235进行编程。  我知道辅助连接器上有 UART 引脚、但不确定用于 nRST 的 XDS110引脚是什么。  有关如何执行此操作的任何文档？  我尝试了 Google、但没有任何看起来相关的东西。  

关于 可正常工作的旧版本-您是否只有十六进制文件？ 或者您能够使用二进制文件构建它吗？ 还是来自源？

您能否尝试从 SDK 而不是完整的应用中构建简单的 GPIO 示例并对其进行编程？

尝试消除会阻止代码运行的其他问题。

我们尝试构建的新版本来自我们认为在旧应用中使用的源代码。

您是指 SDK？  我们尝试加载Benjamin Moore 提供的模块、但这似乎有相同的问题。  

是的、我是从 SDK 中说的。  

由于调试选项太少、这确实是一个棘手的问题。 我将尝试在内部检查我们还能提供什么。