你好，我使用的芯片时CH32V208，我想请教一下，在使用贵公司BLE mesh的配网器例程provisioner_vender_with_peripheral时， 由于环境影响等原因，配网器给节点发消息时常丢包（配网器显示发送成功但是节点没收到），所以选择相同的数据循环发送3次，情况有所好转，但是还是无法完全避免，配网器如果通过厂商自定义模型循环发送透传数据时（代码如图微信图片_20240803001808.png），不论数据长度，只能完成前8次发送，当发送到第9次的时候会出现报错err：-7（发送缓存已满）微信图片_20240803001829.png，加入延时也没用，CONFIG_MESH_ADV_BUF_COUNT_DEF最大只能到16，否则无法配网，报错：Unable set configuration (err:-7)，trans_cnt本来就是最小，为0x01，请问有什么办法可以解决上述问题吗？（或者如何有效避免丢包）

“只能完成前8次发送，当发送到第9次的时候会出现报错err：-7（发送缓存已满）”

报错-7通常有两种情况①发包太快，发包队列满了；②协议栈内存不足。

与情况①相关，图一中的发包逻辑，for循环中10ms就填充一包，会向发包队列中填充vendor_model_cli_send接口中，.trans_cnt结构体成员数值数量的包个数；在当前.trans_cnt是1的情况下，若周围有其他节点发包，转发包也算在发包队列空间内，那么连续执行3个for循环是很可能会队列大小满的。按mesh协议实际发完应用层的一包，需要约70ms，加上其他时间开销，1s内只能安排往外发送10个包。

排查情况②，Ⅰ.检查BLE_MEMHEAP_SIZE是否被改动，改太小了；Ⅱ.检查是否在BLE已连接的情况下才可以复现问题，若是，请下载一份最新EVT，覆盖更新mesh库；Ⅲ.如果在应用层的发包函数中添加了tmos的内存申请接口，检查发包后是否释放。

CONFIG_MESH_ADV_BUF_COUNT_DEF改大后报错-7的问题，这个报错少见，推测还是协议栈ram分配太小导致的，加大BLE_MEMHEAP_SIZE在做尝试。

好像还是不太像诶，请问底层如何判断消息是否发送完成哇？第9次开始报错是不是因为之前的消息没有发送成功或者节点没有收到，导致内存一直被占用，没有释放？也就是说循环发送3次实际上是无效的？

发包方没有接口可以查询发包队列中现存几个包，只能通过报错来表现。查看收包方的打印，看能不能收到包，用来查看发包能不能发出；发包的目标地址，配置为0xFFFF，这个包是所有节点包括本节点都理应收到的。

多收集一些信息：断开BLE，关闭转发功能后，发包频次降低到1s发出1包还会不会报错？EVT包是什么时候下载的，更新到最新EVT的mesh库是否解决。