[参考译文] CC2340R5：最新 F3 堆栈的 MTU 和 PDU 大小问题

我从迹线得到了更多的信息...

目前它看起来像中央（电话）-正在发送大小正确的 LL_LENGTH_REQ 为 TX 和 RX、251 字节、但来自外设的响应是 MAX RX 八位字节：27 和 MAX TX 八位字节 251。

你好、罗伯特！

该问题似乎源于外设 LL_LENGTH_RSP 数据包的最大 RX 八位位组。 您能否 在输入 BLE 任务之后和开始连接之前尝试调用函数 HCI_EXT_SetMaxDataLenCmd、TX 和 RX 八位位组为 251、TX 和 RX 时间为 17000？ 您是否还可以检查此函数的返回值？

这应该将 LL_LENGTH_RSP 的最大 RX 值增加到 251 并解决您的问题。

此致、
Lea

嗨、Lea

我尝试过改变这些… 并添加了一个陷阱以查看命令是否被拒绝。

HCI 返回 HCI_SUCCESS、但 LL_LENGTH_RSP 上的参数永远不会更改 — 添加以下值，仅用于查找 RX 和 TX 上的任何更改。

堆栈中锁定这些值似乎有问题？

void *BLEApp Util_Task (void *arg)
｛

hciStatus_t hstatus；

//注册到堆栈并创建队列和事件
BLEAppUtil_stackRegister()；

//初始化 ble 堆栈
BLEAppUtil_stackInit()；

// robs 测试...

//更改 RX/TX PDU 的初始值和时间、将 RX 设置为最大值 默认情况下 (251 个八位字节、2120us)
#define MV_APP_ADPROJECD_RX_PDU_SIZE 240 //默认值为 251 个八位字节 (RX)
#define MV_APP_advised_RX_TIME 2500 //默认值为 17000us (RX)
#define MV_APP_ADPROJECD_TX_PDU_SIZE 240 //默认值为 251 个八位字节 (TX)
#define MV_APP_advised_TX_TIME 2500 //默认值为 17000us (TX)

//此 API 记录在 hci.h 中
//有关使用此命令的信息、请参阅 BLE5-Stack 用户指南中的 LE 数据长度扩展部分：
//所有适用的文档和配套资料都可以在 TI 开发人员专区 — https://dev.ti.com/中找到
Hstatus = HCI_EXT_SetMaxDataLenCmd (MV_APP_advised_TX_PDU_SIZE、MV_APP_advised_TX_TIME、MV_APP_advised_RX_PDU_SIZE、MV_APP_advised_RX_TIME)；

if( hstatus ！= HCI_Success )
｛
while (1)；
}

//应用程序主循环
对于（；；）
｛

…

}

您好！

从 8.10.01.02 到 9.14.01.16 之间的巨大飞跃很难找出问题。 您可以尝试逐步更改 SDK 版本、以了解哪个版本是导致问题的第一个版本。

或者、您可以尝试查看您使用的最新 SDK 中的 basic_ble 示例是否也存在相同的问题。 通过使用菜单、您可以更改连接的 MTU。 如果您没有看到碎片问题、您可以在此示例基础上创建代码。

此致、
Lea

尊敬的 Lea：

好的、我已设法从最新的 SDK 构建 BasicBle 示例、因此工程中没有自定义代码、而只是对定义的特性进行了更改、以便与我们的目标器件保持一致、并暴露了大小为 240 字节的大特性。

因此、当数据在中央器件和外设之间来回移动时、无法从应用角度对数据进行解码或执行任何操作。

在这种配置下、我看到了相同的问题。 ll_length_Req 从中央器件（电话）和 LL_length_RSP（来自外设 CC2340）是错误的、在其 RX 上限制为 27 个字节、即使它愉快地以全长传输。

我非常确定这是堆栈中的一个问题。 即使使用 HCI 命令、我也无法让它发生变化。  

很高兴直接与 TI 应用开发支持团队进行离线合作、尝试解决该问题（即使共享代码）。 为了取代 CC2541、一年多以来、我们一直在尝试将此器件投入生产、但堆栈和早期器件一直存在问题、以至于无法运行真正实用的应用。

此致

Rob

你好、罗伯特！

很抱歉耽误了很长时间、我想确保在回复之前有备份我的索赔的适当示例。 我已经为 CC2340R5 创建了两个项目。

第一个工程被称为“basic_ble_peripheral_LP_EM_CC2340R53_freertos_ticlang“、并公开具有新特性的新服务、该新特性为长特性（255 字节）。

第二个工程名为“basic_ble_LP_EM_CC2340R53_freertos_ticlang“、是可以发送 GATT 请求的中央器件的示例。 这主要是基于 我几个月前创建的这个例子 (github.com/.../full_ble_GATT_client_LP_EM_CC2340R5_freertos_ticlang)。 不同之处在于此项目增加了能够通过菜单发送 MTU 请求的功能。

我已使用监听器确认、在 CC2340R53 LaunchPad 上使用这两个工程时、GATT 请求完成 251 字节 x 251 字节、这是 BLE 的理论最大值。

这些示例是使用最新的 SDK (9.14.02.16) 完成的。 我希望这将足以让您进行比较、激励自己、并利用这些工作实例来解决您可能遇到的问题。

此致、
Lea

尊敬的 Lea：

感谢您对此所做的努力,但看看您监听器上的事务,您是否没有看到相同的问题 ,其中通过 LL 长度请求 — 即 251 字节 TX 和 251 字节 RX 不被接受,而是这的响应是 27 字节和 251 字节。 即使 MTU 长度被接受、您在一个方向上的传输可能仍然是零散的。 这与我使用旧 SDK 时得到的结果不同。

您是否尝试过扩展对大型数据包的捕获、以查看它们是否分段。  

我必须尝试构建这些示例并使用 Wireshark。 可能需要一些时间、因为我们在这里实际使用 IAR。

此致

Rob

尊敬的 Lea：

我已经尝试从 GitHub 下载并编译 FULL_GATT_SDK.LP_EM-CC2340R5 freertos_ticloang、它似乎没有编译、似乎正在寻找 Client_Ble_ v9.10.0.83、我有 9.14_01_16 可用、它正在尝试使用。

编译错误：

[0]****为项目“Full_GATT_CLIENT_LP_EM_CC2340R5_freertos_ticlang“构建配置“Release“****

[1]“C：\ti\ccs2041\ccs\\utils\\bin\gmake“-k -j 32 all -O

[2]构建文件：“../FULL_GATT_CLIENT.syscfg“
[3]调用：sysconfig
[4]“C：/ti/sysconfig_1.23.2/sysconfig_cli.bat -s “C：/ti/simplelink_lowpower_f3_sdk_9_14_01_16/.metadata/product.json -s “C：/ti/simplelink_lowpower_f3_sdk_9_14_01_16/.metadata/product.json --script “C：/Users/Rob/workspace_ccstheia/full_GATT_client_LP_EM_CC2340R5_freertos_ticlang/full_GATT_client.syscfg -o “syscfg“--compiler ticlang
[5]正在运行脚本...
[6]类型错误:未知属性: numOfDefAdvSets
[7]在 setHelper (C：\ti\sysconfig_1.23.2\dist\webpack：src ts：186：8) 中
[8]位于 Object.set (C：\ti\sysconfig_1.23.2\dist\webpack：src ts：30：10)
[9] at scriptFunc (C：\Users\Rob\workspace_ccstheia\full_GATT_client_LP_EM_CC2340R5_freertos_ticlang\Full_gat_client.syscfg：49：43)
[10]位于 CB (C：\ti\sysconfig_1.23.2\dist\webpack：src ts：112：7)
[11]位于 withDepresectatedAccess (C：\ti\sysconfig_1.23.2\dist\webpack src：ts：14：10)
[12]、在 runAsUserScript (C：\ti\sysconfig_1.23.2\dist\webpack src：ts：61：10) 中
[13]位于 iteatee (C：\ti\sysconfig_1.23.2\dist\webpack：src ts：110：5)
[14] at baseEach (C：\ti\sysconfig_1.23.2\dist\webpack：\sysconfig\node_modules\lodash\lodash.js：530：11)
[15]位于 function.each (C：\ti\sysconfig_1.23.2\dist\webpack：\sysconfig\node_modules\lodash\lodash.js：9409：52)
[16]、路径为 C：\ti\sysconfig_1.23.2\dist\webpack src：ts：108：6
[17]gmake :目标'全部'由于错误而未重制。

[18]*****构建完成****

numOfDefAdvSets SysConfig 不相关吗？

你好、罗伯特！

是的、 numOfDefAdvSets 与 SysConfig 相关。 该工程是为较早的 SDK 创建的、因为我花时间为您的用例升级了示例、所以我正在更新此示例。  

在阅读了我之前的信息后、我才意识到我完全忘记添加我所谈论的项目、因此很抱歉该消息>_>
你可以在这里找到两个项目:

e2e.ti.com/.../MTU_5F00_long_5F00_characteistic_5F00_LP_5F00_EM_5F00_CC2340R53_5F00_freertos_5F00_ticlang.zip

此致、
Lea

尊敬的 Lea：

好的、我成功地构建了您的两个示例并使它们在两个 LaunchPad 上运行。 请注意、我使用的是 CC2340R5 — 而不是 R53。 因此、我更改了 SysConfig 中的目标 CPU 以使其运行。

我设法使用 Wireshark 来查看大数据传输。 当中央器件执行 READ_REQ 时、读取数据是一个大型数据包并且正常工作、但是当我尝试执行 WRITE_REQ （您确实为提供了示例跟踪日志）-外设似乎在没有响应的情况下锁定。

这确实是我们需要检查的写入、因为这些传输使用我们的器件现在显示的最新堆栈变得支离破碎。

仅供参考 — 为了获得速度，我们执行 write_NORSP

在深入研究您的示例之前、您能尝试一下吗？或许可以使用 CC2340R5、因为这也是我们的问题所在。

谢谢

Rob

尊敬的 Lea：

FYI:在测试应用程序中,只有几件看起来错误的事情是 memcpy () 用法,将数据移入和移出长特征,其长度定义为 512 ,但回调中的接收数组为 20 字节。

我还认为 251 是具有数据长度扩展的最大有效载荷大小？

Rob

尊敬的 Lea：

好的、所以我管理你让你的两个项目运行、并使用 241 字节的有效负载数据。 更正了内存分配并捕捉了中央器件中的特性 53 以写入更大的数据块。 在演示中、您曾经只写入了一个字节。

总体结果是它展示了我在我们的项目中的相同问题,即在一个方向上 Central ReadReq（外设到中央）在一个间隔内发送 241 字节的有效载荷,但在另一个方向 上 Central WriteReg（中心到外设）有效载荷被分割成多个最多 27 字节的事务

MTU 设置仍然与您的设置完全相同。

这证实了这些最新 SDK 在 LL 大小为一个方向上似乎存在问题。  

我有这个捕捉,但似乎不能在这里上传目前. 我还可以共享修改后的工程。

下一步是尝试无响应的 WriteReq。 但我希望这一切都是一样的。 RX/TX MTU 设置为 251。

我们能否对此进行更多的调查？ 我们的项目目前被这种情况阻止了。 很高兴能以任何方式提供帮助。

谢谢

Rob

你好、罗伯特！

很好地了解 memcpy 问题、我一定会尽快修复它。 我确实只试读的同时测试,我会试图看看是否写是零碎的,并尽快回到你,我可以。 您能否将您的代码发送给我,让您修复此问题,以便我可以在 GitHub 存储库中修复它,并轻松重现您的问题?

向我发送补丁后、我要尝试做的是更改 SDK 版本、查看此问题开始出现的位置、如果我无法自行找到解决方案、请通知研发部门。

此致、
Lea

尊敬的 Lea：

很抱歉、我无法在此附加任何文件。 您能给我发送任何上传链接等吗？

我认为目前论坛附加文件有问题。

BR

Rob

您好！

tidrive.ext.ti.com/.../6f985194-32d5-4aed-82c9-447132453185
代码： 8FA|Rvj9

您应该可以在 1 天内上传。

此致、
Lea

嗨、Lea

非常感谢 — 我现在上传了两个项目的 zip 文件。

还添加了显示碎片的图像。

PS： 预先通告 — 在中央我硬编码了一个陷阱,以发送 241 字节的大数据包 if( currentGATChar.valueHandle ==55 ),不理想,但试图抓住 app_menu.c 操作。 无法快速确定如何检查特征最大长度。

希望这有所帮助

Rob

您好！

没问题、您的工作已经为我节省了很多时间。
我今天将进行研究、并尝试向您提供我的调查结果的最新信息、

此致、
Lea

您好 Robert：

我能够重现您的问题、其中写入是分散的、但读取不是分散的。 进行研究。
（E2E 很难发送我的嗅探器的图像、但我确实看到了我的嗅探器中持续的 LE-U 传输）

此致、
Lea

您好 Robert：

进行更多测试后、SDK 版本 9.14.00.39 中会出现问题。 SDK 版本 9.12.00.19 可正常运行。 我将尝试找出导致问题的这两个 SDK 版本之间的差异。

此致、
Lea

你好、罗伯特！

在进一步挖掘后、我能够确定导致问题的确切承诺。 此错误是在使用编码 PHY 时尝试修复另一个错误时引入的、但在发布之前我们没有意识到它导致了另一个问题。

您面临的问题是每次 DLE 交换、connMaxRxOctets 和 connMaxRxTime 值将更新为连接的有效值。 这会导致这些值只能下降的问题。 连接开始时、由于中央器件为 TX 使用 27 个字节、从而使外设的 RX 27 个字节的有效值很低、因此这些值很低。 然后、将该值设置为外设的最大值、并卡滞在该值。

目前有一个未合并的 PR 可以解决此问题、我将更多地关注这个问题、并让负责 BLE 堆栈的团队尽快合并 PR。

此致、
Lea

尊敬的 Lea：

感谢您在此方面的工作 — 听起来在不远处有一个积极的解决方案。 当有可以测试和查看的更新时、请告诉我。

祝你一切顺利

Rob

同时、您可以将 SDK 升级到 不包含错误的版本 9.12.00.19、并在发布后升级到 9.20。

尊敬的 Lea：

我正在尝试降级堆栈、然后重新测试所有这些。

在 CCS 中 — BLETestLongCentral 在构建较旧的栈时可以正常运行、但在 BLETestLong（外设）上 — 我在构建中似乎无法克服这个错误。与 BLE_CONFIG_NUM_ADV_SETs 相关。

您是将 CSS 中的编译重定向到较早的 SDK、还是需要使用较旧的 SysConfig、还是重新创建了该工程。 似乎 SysConfig 应该在 ti_ble_config.h 中定义 BLE_CONFIG_NUM_ADV_SETs？ 但我在基于外设的工程中没有定义。 实际上、广播公司下似乎定义了多个广播、

指向我错误操作的任何指针都会 有所帮助 (CCS 新手 — 通常可与 IAR 配合使用、但开始认为 SysConfig 和 SDK 版本可能紧密链接在一起。

270]|^Ω
[271]./app/app_peripheral.c :182 : 13 :警告:调用未声明的函数'BleConfig_startAdvSets'; ISO C99 及更高版本不支持隐式函数声明[-Wimplicate-function-declaration]
[272] 182 | BleConfig_startAdvSets（外设 AdvHandles、NULL、BLE_CONFIG_NUM_ADV_SETs）；
[273]|^
[274]../app/app_peripheral.c：182：64：错误：使用未声明的标识符“BLE_CONFIG_NUM_ADV_SETs“
[275] 182 | BleConfig_startAdvSets（外设 AdvHandles、NULL、BLE_CONFIG_NUM_ADV_SETs）；
[276]|^Ω
[277]../app/app_peripheral.c：221：42：错误：使用未声明的标识符“BLE_CONFIG_NUM_ADV_SETS“
[278] 221 | uint8_t 外设 AdvHandlesStatuss[BLE_CONFIG_NUM_ADV_SETTS]；
[279]|^
[280]./app/app_peripheral.c：222：5：警告：调用未声明的函数'BleConfig_initAdvSets'；ISO C99 及更高版本不支持隐式函数声明[-Wimplicate-function-statement]
[281] 222| BleConfig_initAdvSets（外围设备 AdvHandles、外围设备 AdvHandlesStatuses）；
[282]|^
[283]../app/app_peripheral.c：223：25：错误：使用未声明的标识符“BLE_CONFIG_NUM_ADV_SETs“
[284] 223 | for (int I = 0；I < BLE_CONFIG_NUM_ADV_SETs；I++)
[285]|^á
[286]../app/app_peripheral.c：232：5：警告：调用未声明的函数'BleConfig_startAdvSets'；ISO C99 及更高版本不支持隐式函数声明[-Wimplicate-function-statement]
[287] 232 | BleConfig_startAdvSets（外围设备 AdvHandles、NULL、BLE_CONFIG_NUM_ADV_SETs）；
[288]|^
[289]../app/app_peripheral.c：232：56：错误：使用未声明的标识符“BLE_CONFIG_NUM_ADV_SETs“
[290] 232 | BleConfig_startAdvSets（外设 AdvHandles、NULL、BLE_CONFIG_NUM_ADV_SETs）；

BR

Rob

你好 Rob！

您是正确的、不同的 SDK 版本之间的 SysConfig 存在一些差异。 您可以找到我在该 TI 驱动器中编写的所有代码。 特别是、您可以复制 BLETestLong_9.12示例的 SysConfig 文件

tidrive.ext.ti.com/.../6f985194-32d5-4aed-82c9-447132453185
代码: @va85iQs.

此致、
Lea

尊敬的 Lea：

最终回到这个问题。 我使用了 9.12 SDK（外设端）的示例 — 但我仍然看到相同的碎片。  

中央控制器是否也需要运行旧栈、或者这只是一个外设问题。  

我仍在 CSS 内部工作、目前仅使用两块 TI 开发卡对此进行测试。

此致

Rob

您好！

对不起,晚答复,我在复活节假期。
该问题只应出现在外设侧、而是在中创建的  9.14.00.39。

使用我在 TI 驱动器中提供的示例应该可以。 我已经用手机作为中心进行了测试。

此致、
Lea

尊敬的 Lea：

我自己回来了。  我重新审视了这里、构建了您的示例、其中一个中央器件和外设在两个 CC2340R5 开发板上运行。 我仍然看到长写入请求被碎片化。

想知道您是如何使用手机实际发送大型 Write_Req 的。 您是否有自定义应用程序。 由于使用应用程序的浅蓝色资源管理器创建这些大块只是很难确保写入正确的字节数。

我的 BLETestLongCentral 使用 F3 SDK 9.11.1.19

我的 BLETestLong  （外设）也使用 F3 SDK 9.11.1.19

以下是监听器、显示了中央向外设写入 241 字节时仍然发生的碎片。

有什么想法吗？ 您是否有实际 Write_Req 的监听器日志？

BR

Rob

罗伯特下午好！

今天上午我发了一条消息,说我会为你测试这个,但它没有发送显然,对不起。
我已经使用监听器确保 BLETestLong_9.12 工程按预期工作。 这是在 CC2340R53 和我的手机上使用蓝牙应用程序进行的测试。

您可以看到、在 MTU 事务之前、最大读取值为 22 字节、最大写入值为 18 字节

然后我用手机发送 MTU 事务请求、CC2340R53 外围设备以 251 的 MTU 进行回复。 在 MTU 事务之后、还会立即发送数据长度更新事务、所有 RX 和 TX 值均设置为 251 字节

最后、完成此操作后、我的 RX 和 TX GATT 事务都可以一次性读取所有内容、而无需拆分数据包

我怀疑您可能遇到的问题是您忘记了 MTU 事务、或者您的中心在 MTU 事务后不会自动运行数据长度更新事务。 在这种情况下、一种解决方案是在外设中的 MTU 更新回调中自行执行此 DLU 事务。

此致、
Lea

尊敬的 Lea：

我现在已经开始和结束了这方面的工作。 针对中央运行堆栈和外设运行堆栈 9.12 使用 CC2340R% Dev Kit 时、我仍没有进展、无法正常运行编译。

我真的需要更多的支持,这个,已经燃烧了几个月,这个项目没有得到任何地方.

在您上次的回复中、您提到自己在 MTU 更新回调中执行 DLU 事务。 您是否有这方面的示例？

 在我们用于对此问题进行故障排除的示例中、我找不到任何回拨。 我担心您不会使用开发板对此进行测试
运行此 SDK 的软件包。 因此、我可能也会因 CC2340 中央 SDK 问题而跳闸。

我肯定在执行 MTU 请求 — 堆栈似乎响应正常 （是否因此修改了堆栈中的设置）
命令我无法分辨）。

最后,在你发送的图像上,最后没有显示一个完整的 241 字节中央写入（下半部分）-看破成小包装? （如果我错了，请纠正我）-所有的内容都不像我的 27 字节块那么小。

此致

Rob

您好！

我现在正在旅行,我给你一个简短的答案,因为我没有太多的时间,我将在下个星期更深入,对不起。

241 字节中央是因为我发送了一个 241 字节长的数据包,这只是一个长 gibberish 字符串,我没有检查它是否超过 255。 我可以发送更长的时间,这只是为了证明我们可以发送超过 23 字节在这个版本。

我肯定是用开发板测试这个,因为它是我在办公室里唯一的东西,反正哈哈。

您是否在监听器中的 MTU 更新后看到 DLU 数据包？ 这是判断此方法是否有效的关键部分。

此致、
Lea

尊敬的 Lea：

好的、这是我设法达成的目标。

使用 9.12.00.19 SDK、我成功构建了一个现在可在读写时实现长数据包的外设器件。 但这只是一种情况
使用作为连接中心运行的手机。 当我使用运行 CC2340R5 开发板的中央设备时、问题仍然集中在一个设备中
所以非常不确定具体的情况。 MTU 更新和 LL 交换似乎类似于当电话是中心时。

在那里,我设法重新生成我们基于 9.12.00.19 SDK 的应用程序,并再次证明通过更大的传输,所以一切都很好。

刚刚发现新版本 9.20.00.81 已下降。 现在我要讨论一下、检查它的最终解决方案。

令人头疼的是、在 IAR 上的栈之间迁移内部工程工作是一件事，我不能只是参考新的栈 — 通常必须通过 BLE Demo 应用再次构建。 想知道 TI 是否有意为栈创建 bin 库文件、而非所有源文件？

无论如何、将使用 9.20.00.81 进行重建、并告诉您它是如何进行的。

至于为什么我的 9.12.00.19 中央仍然做碎片写入,我只是不知道。

祝你一切顺利

Rob

您好！

对于您的 IAR 升级问题、我建议您研究 原始 SDK 和目标 SDK 的两个文件之间的差异：
- examples\rtos\LP_EM_CC2340R53\ble\basic_ble\freertos\iar\basic_ble_LP_EM_CC2340R53_freertos_iar.ipcf
- examples\rtos\LP_EM_CC2340R53\ble\basic_ble\freertos\iar\makefile

这些是添加要构建的新文件或其他更改的文件。 请参阅、例如 basic_ble 工程中的差异、其中 9.20 添加了 COEX 和 PawR 文件。

如果问题在 9.20 上得到解决、请保持更新。

尊敬的 Lea：

因此、仍然可以在 IAR 环境中使用 BasicBLE 演示和编译。 之后我应该能够带来我们的应用程序代码并进行测试。

我发现适用于 IAR 的新 SDK 及其设置存在很多问题。 我想我现在已经有了 basicBLE Building、但我想向您提供我发现的问题的列表、以便团队可以在下一个版本中解决、从而使其他用户更容易解决。

这是我到目前为止的笔记。 似乎正在建设。 您还应注意，我的工作文件夹位于不同的驱动器盘符上，并且文件夹名称中包含空格 — 因此一些更改只是在$PROJ_ON 等附近添加““、以确保传递整个文件字符串。 我可以看到 TI 已经在最新栈中的许多地方添加了此功能。

我的许多其他问题都与创建的 IAR 工程文件未引用正确的位置有关、我还可以看到 TI 已在/freeRTOS 中移动了 basicble.syscfg 文件 以及在\common\startup 中移动了 main_freertos.c

我还没有修复一个关键区域、但设法解决方法是使用“command_runer“的预编译命令、它似乎使用.exe、我假设位置
中对.syscfg 进行了硬编码、并且不正确、因为它现在已移至\FreeRTOS。

对于我的权变措施、我更正了 python 脚本来可以正常运行并运行该脚本。

下面列出了我在 IAR 工程上正确编译需要执行的操作。

新 SDK 发布日期 ：9.20.00.81

这将再次引入编译问题。
BasicBLE 的库存演示未正确设置。  

问题：  

1. 将文件夹复制到工作区域中：对于示例、请从 SDK 中复制。
   \app
   \common
   \FreeRTOS
2. 工程文件位置引用错误。 需要编辑.EWT 和.EWP、查找在$PROJ_ON DIR\C：\ti\simplelink_lowpower_f3_SDK_9_20_00_81\中引用的文件 、然后更改为$COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR
3. basic_ble.sysconfig 不再位于工程路由文件夹中、请将其重新连接到\freeRTOS
4. main_freertos.c 不再位于 route 文件夹中、请在\common\Startup 重新连接它

运行 SysConfig GUI 时出现问题。 缺少清单文件。

这是因为“package.json“已移动到文件夹\app 中

配置查看器命令行应更改为添加\App 文件夹：

“$SysConfig_root$\nw\nw.exe““$SysConfig_root$\app“--compiler IAR --product “$SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR$\.metadata\product.json““--output“  ““““$PROJ_ON DIR$\“““““$file_PATH$\“

SysConfig.CLI 执行出现问题。

编译后操作失败。

现在有 4 个单独的命令行。预编译和编译后处理。

查找我们的$PROJ_ON 位置的任何文件引用、并添加““以允许显示文件夹空格、例如$TARGET_BPATH$.out 应该是“$TARGET_BPATH.OUT“

$TARGET_BPATH$.hex 应为“$TARGET_BPATH.HEX“

“$PROJ_ON DIR$\$PROJ_ON FNAME$.ewp“

最后一个问题是用作预编译步骤的 command_runner.py、它看起来不在工程文件夹之外：

DEF find_syscfg_file (search_dir：path)：

   “““返回在 search_dir 或无中找到的第一个.syscfg 文件。“““

   files = list (search_dir.globb（“*。syscfg“）)

   如果文件不存在、则返回 files[0]

更改为

DEF find_syscfg_file (search_dir：path)：
   “““返回在 search_dir 或无中找到的第一个.syscfg 文件。“““
   FILES = list (search_dir.globb（“*。syscfg“）)
   如果文件不存在、则返回 files[0]

或（更好）

DEF find_syscfg_file (search_dir：path)：
  “““从工程树返回首选的.syscfg 文件、或选择“None“。““
  Preferred = search_dir /“freertos“/“basic_ble.syscfg“
  如果 preferred.exists()：
        首选返回

  FILES = list (search_dir.globb（“*。syscfg“）)
  如果文件不存在、则返回 files[0]

未修复 IAR、因为 IAR 似乎使用 commands_runner.exe 而不是 python 脚本。

 解决方法是强制它使用编辑后的.py 脚本。 编辑预编译行。

更改：

$SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR$/tools/ble/oad/commands_runner --cfg_file “$PROJ_ON DIR$\ti_ble_oad_prebuild.cfg“--compiler IAR --EWP “$PROJ_ON DIR$\$PROJ_ON UFENAME$.ewp“--config “$CONFIG_NAME$\“--iarbuild“$Toolkitk_DIR$\sysconfig_build\$CLI_ execute_build\$CLI_安装_CLI_-$_CLI_

收件人：

python “$SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR$/tools/ble/oad/commands_runner.py --cfg_file “$PROJ_ON DIR$\ti_ble_oad_prebuild.cfg“--compiler IAR --ewp “$PROJ_ON DIR$\$PROJ_ON LOWFNAME$EWP“--config “$CONFIG_NAME$\“--iarbuild “$SIMPLELINK_INSTALL_DIR$CLI\$DEL_DIR$$_安装\SysConfig_CLI_- execute_CLI\$$_

希望这有所帮助。

在我运行完整的应用程序并使用新 SDK 验证其中的大数据包后、我还会告诉您。

此致

Rob