1. 先还原现场：CC2642R1 脱离 IAR 后，EIDE 导入为什么会失败
如果你正在用 CC2642R1（CC13x2/26x2 SDK 5.20）做 BLE 开发，大概率会经历这样一个阶段：IAR 5.80 用着没问题，但界面太重、补全太弱、Git 管理也不顺手，于是想把整个工程搬到 VSCODE + EIDE 上。这个思路本身没问题，官方 SDK 的例程目录也确实是按这个链路设计的，但真正动手时，很多人会卡在第一步——EIDE 导入项目时选完 multi_role.eww，要么直接报错，要么导入后工作区一片空白，构建任务里找不到 sysconfig_cli，烧录时 srfprog.exe 又提示命令不可用。
这三个现象看起来是三个独立问题，实际上它们指向同一件事：VSCODE 需要的目录结构，是 IAR 先帮你生成出来的。原文里那句「请先用 IAR 打开工程，否则 VSCODE 导入失败」不是建议，是硬性前置条件。IAR 在首次打开 multi_role.eww 时，会在工程目录下补齐 .metadata、syscfg 相关的中间文件以及协议栈产物目录，EIDE 导入时正是靠这些文件来识别工程结构和构建配置。你跳过 IAR 直接导入，EIDE 拿到的就是一个「缺胳膊少腿」的目录，导入失败几乎是必然的。
这篇要解决的就是这个排障场景：把「导入失败 / 找不到构建任务 / 烧录命令不可用」这三类现象，交给走 TaoToken 的 Codex 来逐项核对。TaoToken 在这里的角色很明确——只提供 Key 和 Base URL，让 Codex 能稳定跑起来，它不参与 EIDE 导入、协议栈生成或 srfprog 烧录本身。你需要做的是把真实的目录树、.eww 路径、.syscfg 路径和 EIDE 的报错提示贴给 Codex，让它对照正确顺序帮你定位差在哪一层。
适合谁看：已经装好 IAR 5.80 和 VSCODE、正在尝试 CC2642R1 脱离 IAR 界面开发、并且已经遇到导入或构建任务问题的嵌入式工程师。如果你还没走到这一步，也可以先按本文的顺序把环境搭起来，再回头看排障部分。
2. 前置准备：TaoToken 的 Key 与 Codex 接入配置
在开始排查之前，先把 Codex 的调用链路配通。这一步只做一次，后面所有排障对话都复用同一把 Key。
打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 注册账号，进入控制台创建 API Key。创建完成后，你会拿到一串以 sk- 开头的密钥，先复制保存好。接着在 Codex 的配置里，把 Base URL 填成 https://taotoken.net/api，API Key 填你刚创建的那把。注意 Base URL 后面不要多加斜杠或路径，保持 https://taotoken.net/api 这个形式即可。
配置完成后，你可以先用一句简单的话测试连通性，比如让它复述一段你贴进去的目录结构。如果它能正常返回，说明 Key 和 Base URL 都生效了。这里要强调一点：TaoToken 只负责模型调用的通道，你的 EIDE 插件、IAR 工程、sysconfig_cli、srfprog.exe 都不经过它，所以排障时不要指望它去「操作」你的工程，它的价值在于帮你比对路径、复述步骤、指出目录层级差异。
如果你后续还要做长期编码或 Agent 类的自动化任务，可以再了解 Coding Plan；如果只是想验证模型对话是否正常，模型对话入口也够用。但本篇的核心是排障，Key 配好就能开始。
3. 可复制配置：把工程目录和报错喂给 Codex 的正确姿势
排障的效率，取决于你给 Codex 的上下文质量。很多人只丢一句「EIDE 导入失败怎么办」，得到的回答必然是泛泛而谈。正确的做法是把下面这几类信息一次性贴进去。
第一类是 EIDE 的导入提示原文。导入失败时，VSCODE 右下角或输出面板会给出具体报错，比如找不到某个 .ewp、无法解析 .eww、或者工作区切换后没有识别到构建配置。把这些原文完整复制，不要截断。
第二类是工程目录树。在 C:\ti\simplelink_cc13x2_26x2_sdk_5_20_00_52\examples\rtos\CC26X2R1_LAUNCHXL\ble5stack\multi_role\tirtos\iar 这个路径下，用命令列出目录结构：
cd C:\ti\simplelink_cc13x2_26x2_sdk_5_20_00_52\examples\rtos\CC26X2R1_LAUNCHXL\ble5stack\multi_role\tirtos\iar
dir /s /b > tree.txt
把 tree.txt 的内容贴给 Codex，重点让它看有没有 .metadata、syscfg、multi_role.syscfg、以及协议栈相关的产物目录。如果这些缺失，基本可以确认是 IAR 没有先打开过工程。
第三类是 .eww 和 .syscfg 的真实路径。.eww 就是你在 EIDE 导入时选的那个文件，.syscfg 通常在工程根目录或 syscfg 子目录下。把这两个绝对路径写清楚，Codex 才能帮你判断 EIDE 的工作区切换是否指向了正确的层级。
一个可以直接复用的提问模板是这样的：
我在 CC2642R1 的 SDK 5.20 例程上做 VSCODE + EIDE 开发。
工程路径：C:\ti\simplelink_cc13x2_26x2_sdk_5_20_00_52\examples\rtos\CC26X2R1_LAUNCHXL\ble5stack\multi_role\tirtos\iar
EIDE 导入时选择的文件：multi_role.eww
导入后的报错原文：[粘贴报错]
当前目录树：[粘贴 tree.txt 内容]
请帮我判断：1）是否缺少 IAR 首次打开生成的目录；2）EIDE 工作区应该切到哪一层；3）sysconfig_cli 构建任务为什么没出现。
这样问，Codex 才能给出有指向性的判断，而不是让你「重新安装插件」。
4. 验证请求与成功结果：让 Codex 复述正确步骤顺序
配置和上下文都准备好之后，下一步是让 Codex 复述一遍正确的操作顺序，并指出你当前目录差在哪一层。这一步很关键，因为很多人不是不会操作，而是顺序错了。
正确的顺序是：先在 IAR 5.80 里打开 multi_role.eww，让 IAR 生成 VSCODE 所需的目录和中间文件；然后用 VSCODE 打开该目录，配置 IAR 路径给 EIDE；接着选择 EIDE 的「导入项目」，选 multi_role.eww 导入，导入完毕后点击「切换工作区」；关闭 VSCODE 工程，把自制工具 build_configPkg.exe 和 open_syscfg 放入根目录；运行 build_configPkg.exe 生成协议栈产物；重新打开 VSCODE 项目；添加 sysconfig_cli 构建任务；最后编译和烧录。
你可以让 Codex 针对你的目录树逐项打勾，比如：
请对照以下顺序，逐项告诉我当前目录是否满足：
1. IAR 是否已打开过工程并生成 .metadata
2. EIDE 导入的 .eww 路径是否正确
3. 工作区是否已切换到工程根目录
4. build_configPkg.exe 是否已放入根目录并运行
5. sysconfig_cli 构建任务是否已添加
6. srfprog.exe 目录是否已加入系统环境变量
如果 Codex 指出第 1 项不满足，你就回到 IAR 重新打开一次工程；如果第 5 项缺失，就检查 sysconfig_cli 的构建任务命令是否写对。原文里给出的命令是：
${SYSCONFIG_ROOT}\sysconfig_cli.bat -s ${TI_SDK}\.metadata\product.json -o syscfg --compiler iar ${ProjectRoot}\multi_role.syscfg
注意这里的 ${SYSCONFIG_ROOT}、${TI_SDK}、${ProjectRoot} 都是 EIDE 的环境变量，你需要确认它们在 EIDE 的设置里已经正确指向 SDK 和工程根目录。如果这些变量为空，构建任务即使添加了也跑不起来。
烧录环节，srfprog.exe 默认在官方烧录工具目录下，你需要把它的所在目录加入系统环境变量 PATH，然后重新打开一次 VSCODE，否则新环境变量不会生效。这一步很多人会忽略，导致烧录命令一直提示不可用。
5. 本篇常见错排查：导入失败、构建任务缺失、烧录不可用
5.1 EIDE 导入失败，提示找不到工程文件
最常见的原因是 .eww 路径选错了。EIDE 导入时要求选择的是 IAR 的工作区文件 .eww，不是 .ewp 项目文件。如果你选的是 .ewp，导入会失败或导入后结构不完整。另一个原因是 IAR 从未打开过该工程，导致 .metadata 和 syscfg 目录缺失。解决办法就是先用 IAR 5.80 打开一次 multi_role.eww，等 IAR 完成索引后再关闭，然后回到 EIDE 重新导入。
5.2 导入成功但找不到 sysconfig_cli 构建任务
sysconfig_cli 不是 EIDE 自动生成的，它需要你手动添加，或者由 build_configPkg.exe 运行后生成。如果你跳过了第 5 步直接打开 VSCODE，构建任务列表里自然没有它。检查顺序是：先确认 build_configPkg.exe 已放入根目录并成功运行，再确认 multi_role.syscfg 文件存在，最后在 EIDE 的构建任务里手动添加 sysconfig_cli，命令按上一节的模板填写。如果 ${SYSCONFIG_ROOT} 未定义，去 EIDE 设置里补上 SDK 中 sysconfig 工具的路径。
5.3 烧录时 srfprog.exe 命令不可用
这个问题的根因几乎都是环境变量没生效。你把 srfprog.exe 所在目录加入 PATH 后，必须完全关闭 VSCODE 再重新打开，因为 VSCODE 启动时才会读取最新的环境变量。如果重开后仍然不可用，在 VSCODE 的集成终端里执行 where srfprog 确认路径是否被识别。另外，烧录前要确保协议栈产物已经生成，否则即使烧录命令能跑，目标板也可能无法正常运行。
5.4 编译通过但运行异常
如果编译没有报错，但烧录后设备行为不对，优先检查 sysconfig_cli 生成的配置文件是否与当前工程匹配。有时候 build_configPkg.exe 运行时选择的路径不对，导致协议栈产物放到了错误的目录。让 Codex 帮你比对 syscfg 输出目录和工程引用目录是否一致，通常能快速定位。
6. 把这次排障变成可复用的提问模板
跑通一次之后，建议你把这次用到的目录树、报错原文、正确步骤顺序整理成一个模板文件，放在工程根目录下。下次换例程或者换 SDK 版本时，直接把模板里的路径替换掉，再让 Codex 按同样的逻辑核对一遍。这样你就不用每次从零开始描述问题。
如果你还想继续用同一把 Key 排查编译告警，可以回到 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 确认 Key 状态，然后在 Codex 里把编译输出的 warning 列表贴进去，让它按优先级分类。长期做 CC2642R1 开发的话，把 Coding Plan 配好，后续的代码补全和 Agent 任务也能复用同一套接入配置。API Keys 和接入文档在需要时再查即可，日常排障用模型对话入口就够了。
实测下来，这套流程最大的价值不是让 Codex 替你操作，而是让它帮你把「我以为我做对了」和「目录实际长什么样」之间的差距指出来。CC2642R1 的环境搭建本身不复杂，复杂的是那些藏在顺序里的隐式依赖，一旦顺序对了，后面就顺了。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
