[参考译文] CC3235MODASF：已配置 GPIO 上拉、但无法正常工作

您好！

请点击此处 https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1069727/cc3235modasf-gpio-pull-up-don-t-seem-to-work

显然、内部上拉强度不够高、因此建议使用一个外部电阻器。

什洛米

尊敬的 Shlomi、感谢您的回复(尤其是在周日！)、

我已经看到过那个帖子、但恐怕这个帖子无法真正回答这个问题。  硬件指南中提到的上拉电流通常为10uA。  足够将10兆欧的"范围"探头拉高、并且我已经看到这些上拉电阻在 CC3235MODASF 上对其他项目(一个项目我们现在已经制作了超过500个)都起作用、因此我非常确定我的问题(如果不是另一个帖子的 OP 的问题) SDK 中出现了问题-除了我现在使用的是 Code Composer 12.5 (而不是10.0)、SDK_7_10_00_13而不是 SDK 4_20_00_07以外。  我同时使用的是 Uniflash 8.4、而不是6.2 (但我怀疑这种更改是否可能实现)。

当然、SysConfig 在这两种环境之间似乎有很大的差异。

(我应该补充一点、我*预计*一个手指在一个弱上拉的输入上移动、由于人体电容接近50或60Hz 的电源线而触发它。  3.3V 时10uA 是330k 的等效电阻、因此10M 探头几乎不会发出刺耳声-您是否熟悉欧姆定律？  我意识到,如果你的生活是纯粹的软件,你可能不是)。

Chris、您好、谢谢您提供的信息。 周日是一个工作日这里(周末是改变1天:))。

您是说它以前在相同的硬件上工作、但现在却是在更旧的 SDK 上工作、还是在不同的硬件上工作？

为了避免这成为我的硬件、我取了一个运行旧固件(使用旧 SDK)的旧电路板、然后测量上拉电压和电流。  正如预期的那样、打开时设置开关上的电压恰好是电源电压(在本例中为新 CR2电池提供的3.2V)。  我使用了老式动圈式电表来测量上拉电阻可以提供的电流-输入电流为8uA、这与数据表中的数值(10uA)非常接近。

当我使用新项目更新电路板时、在开关上测得的电压为零(并且电流为零)。

关于我的新项目(或使用更新版本的 SDK)的一些方面会打破上拉。  如果我上传这两个项目文件会有所帮助吗？

提前感谢  Chris、

最后、我将旧项目推到了新电路板上、上拉电阻按预期工作、这再次表明我的新项目驱动 GPIO 设置的方式有问题。

我花了很多时间尝试对这个问题进行三角分析。  为此、我已经将源文件从 CCS12.5环境回迁移到 CCS10.0环境中。  我发现、如果我使用 CCS10进行构建、则上拉电阻在新旧硬件上都可以正常工作。  但是、如果我使用 CCS12.5进行构建、它们就不会。

这对我使用的是哪个版本的服务包或我使用的是哪个版本的 Uniflash 没有任何区别

遗憾的是、我的应用在 CCS12.5中使用较新版本的 UART2、因此它在 CCS10.0符合性时实际上无法正常运行、但它足够允许我确认两个 GPIO22 (我的设置引脚)上的上拉电阻器均处于活动状态、 以及 GPIO6 (我将其用作测试输入)上的、符合10.0

我已经尝试让 syscfg 东西尽可能接近,考虑到差异,我已经附加了 zips 的一个下工作10.0和对(通信和图像)为12.5,如果你能够审查我可能做了什么错.

e2e.ti.com/.../syscfg_5F00_125.zipe2e.ti.com/.../syscfg_5F00_10.0.zip

您好！

它无法与服务包或 Uniflash 相关。

可能是 SYSCFG 的原因所在。

让我在内部询问谁是 syscfg 的专家、以在这里提供帮助。

此致、

什洛米

期待您的回复。  

还有一点信息：在比较项目时、我注意到"正在工作"项目的初始堆栈空间设置为2048、而不工作的空间设置为1024 -更改此值没有区别。

感谢您的持续帮助。

当然,我应该明天在办公室,并试图看看我是否能测试自己。

您好！

我可以分享一点、在我看来、使用新的 CCS/syscfg、这个过程可重现。

我将下载旧版本、然后重试以确保。

如果这是 syscfg 问题、我需要查看谁可以提供帮助并重定向。

此致、

什洛米

很高兴知道它可以重现。  如果您需要更多的项目要素以进行更深入的诊断、请告诉我。

我尝试了 CCS10+syscfg1.8、它可以正常工作。

CCS11+SYSCfg1.12不再工作。

让我从内部看看谁是合适的专家来提供帮助。

什洛米

好的-听起来像是一个明显的错误-或者较新的 SysConfig 要求用户"编写一些新的东西"、这对您和我都不了解。  

为了便于参考、我尝试使用 CCS 12.5、它使用 syscfg 1.18。

清除、感谢确认。

在花了一些时间绕过所生成代码的各个位、查看库的源代码之后、 而,我发现 pin.c 包含的代码,以设置焊盘(这-是天真的-我没有意识到'焊盘'是不同的'GPIOs'-但现在我知道)。  此软件中的引脚编号是模块内 IC 上的引脚编号、而不是模块上的引脚编号(一旦您知道就会清晰可见...)、这需要花费我一段时间才能理解。 -我通过 研究 SWU543A 的第16.8.1章得到了这一点

在导航这些迷宫后、我发现通过将以下代码添加到主线程、可以开启上拉电阻：

对 PinConfigSet ()的调用会执行我需要的操作。

对 GPIO_setConfig ()的注释掉的调用——我原本期望它能够完成必要的工作——不能。

目前、我有一个权变措施、可以在使用较新工具集的同时保持项目进度。

我仍然认为这不应该是必需的、并期待 TI 给出"正确"的答案。  请继续尝试找到一个,如果不是为我,为那些其他可怜的灵魂在那里...

感谢更新、仍在尝试了解此代码的相关人员。

什洛米

很抱歉响应出现延迟、感谢您提供此信息、我现已在"工具"中创建了新主题。

我发现了另一个异常- GPIO9在配置时不能作为输出。

我想我可能已经接近理解出了什么问题了-见

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1343815/launchcc3235mod-sysconfig-not-setting-up-gpio-pull-ups-correctly

在删除 GPIO 后、似乎 SysConfig 并不总是能正常工作。

感谢 Chris 的信息。

让我们看看工具团队会用什么回应。

此致、

什洛米

Chris 和 Shlomi、

我下载了上面的 zip 文件(syscfg_10.0.zip 和 syscfg_125.zip)、并注意到它们之间是 common.syscfg (正如预期的那样、10.0版本尝试反向移植一些更改)、并且它们之间使用的 SDK 也不同。  为了确定该问题是由于 SysConfig 更改还是 SDK 更改所致、我在命令行中运行以下命令：

C：\ti\sysconfig _1.8.0\sysconfig_cli.bat --product c：\ti\simplelink_cc32xx_sdk_4_20_00_07\.metadata\product.json --output c：\temp\1.8\"C：\temp\syscfg_10.0\common.syscfg"

C：\ti\sysconfig _1.12.0\sysconfig_cli.bat --product c：\ti\simplelink_cc32xx_sdk_4_20_00_07\.metadata\product.json --output c：\temp\1.12\"C：\syscfg_10.0\common.syscfg"

C：\ti\sysconfig _1.8.0\sysconfig_cli.bat --product c：\ti\simplelink_cc32xx_sdk_7_10_00_13\.metadata\product.json --output c：\temp\1.8_newSDK\"C：\temp\syscfg_10.0\common.syscfg"

C：\ti\sysconfig _1.12.0\sysconfig_cli.bat --product c：\ti\simplelink_cc32xx_sdk_7_10_00_13\.metadata\product.json --output c：\temp\1.12_newsdk\"C：\temp\syscfg_10.0\common.syscfg"

第3条命令失败、因为较新的 SDK 使用较旧版本 SysConfig 中不提供的功能。  这也是我没有尝试将较新脚本与 SDK/SysConfig 的不同版本进行比较的原因所在、它的更改与旧版 SDK 不兼容。

在其他情况下、我观察到的是前两个文件夹(较旧的 SDK、不同版本的 SysConfig)中的输出是相同的。  最后一个文件夹中的输出与前两个文件夹大不相同、因为 SDK 现在似乎要为 GPIO 生成完全不同的结构。  因此、这看起来是 SDK 中的变化导致了该差异、而不是 SysConfig 中的变化。

如果在此设置中遗漏了一些内容、请告诉我。  否则、Shlomi、您能否将此问题转发给 SDK 团队中的某个人？

达里安

谢谢 Darian、

正如我所说的、在我看来、这看起来像是 SDK 中 TI 驱动程序层的某个东西。 您知道哪个组负责处理 CC32xx base SDK (不知道具体是 Wi-Fi)？

此致、

什洛米