Hi
我在测试write命令的时候,发现如果写很大的数据,比如100byte的话,多次wirte会导致cybt343026-01重启。以下是我用64bytes进行多次测试的情况
1. 多次发送后会出现失败的情况(我大概测试了7次左右)。请问该如何解决这个问题
2. 出现1的情况后,我想抓用spy抓log给你们分析,但是发现value里写入的64bytes的数据,但是spy收到的数据长度是33 byte?工具是会限定数据长度吗?然后就没有重现1的现象
3. 所以wirte no rsp支持写多大的数据呢
已解决! 转到解答。
Hi,
关于Write Command中Value长度的细节,我截图了Specs中的相关内容给您参考:
具体而言,它实际的长度会与Server端的对该Attr的设置有关。即您还需要结合对端设备的情况来考量。
至于程序崩溃重启的问题,我还是继续建议您使用JLink或者MiniProg等调试器来进行步进调试以分析原因。
<<<<<<<<<<<<<>>>>>>>>>>>>>
Sincere regards from C. L.
<<<<<<<<<<<<<>>>>>>>>>>>>>
Hi,
"write no rsp"支持的数据size和GATT一致。GATT中Attribute MTU Size的取值范围是23-512bytes。
如果您需要一次写100bytes,您需要设置您的max_attr_len为大于100bytes,比如128bytes。并且需要注意,max_mtu_size的取值应为max_attr_len+5,故修改max_attr_len的同时也需要修改max_mtu_size,比如上述例子中,max_mtu_size也应相应地设为133bytes。
此外,您也需要注意一次write的数据不要太大,以免max_mtu_size超过512bytes。
要修改这个参数,请到工程目录中找到“wiced_app_cfg.c”文件,然后,修改其中的“wiced_bt_cfg_settings”变量,找到其中的“.gatt_cfg”子结构变量,然后修改“.max_attr_len”和“.max_mtu_size”。
另外,从您的日志来看,我猜测可能是上述参数没有设置好,导致您预计发送64bytes实际只发送了33bytes;并且因为buffer预留不匹配而可能发生了字符串超写等异常,导致内存溢出,造成栈数据非法覆盖,进而引发了系统重启。
<<<<<<<<<<<<<>>>>>>>>>>>>>
Sincere regards from C. L.
<<<<<<<<<<<<<>>>>>>>>>>>>>
Hi,
在变量“wiced_bt_cfg_settings”的尾部,应该还有如下的定义:
#ifdef CYW20706A2
.max_mtu_size = 517, /**< Maximum MTU size for GATT connections, should be between 23 and (max_attr_len + 5) */
.max_pwr_db_val = 12 /**< Max. power level of the device */
#else
.max_number_of_buffer_pools = 6, /**< Maximum number of buffer pools in p_btm_cfg_buf_pools and by wiced_create_pool */
.rpa_refresh_timeout = WICED_BT_CFG_DEFAULT_RANDOM_ADDRESS_NEVER_CHANGE, /**< Interval of random address refreshing - secs */
#endif
您可确认一下这里是否正常。并且顺便分析一下其他的参数配置是否正常。
如果这些设置没有发现异常,那您可以尝试使用JLink等调试器进行步进调试,以便更好地发现问题。
您这个问题仅从log等日志应该无法分析出根本原因,因为它并没有提供实质的输出,故任何猜测都有可能。
<<<<<<<<<<<<<>>>>>>>>>>>>>
Sincere regards from C. L.
<<<<<<<<<<<<<>>>>>>>>>>>>>
Hi,
您这些参数是没有问题的。
另外如果使用了BTSpy后没有复现这个现象,可能是插入的额外的输出缓解了执行的频度,降低了系统各部分相互影响的可能。
此外,需要和您确认一下,您是在己方设备上发送"write no rsp”然后导致己方设备崩溃重启,还是对方设备在频繁接收请求后崩溃重启?并且您BTSpy抓取的,是己方设备(发送write请求的设备)的trace,还是对方设备(接收write请求的设备)的trace?
<<<<<<<<<<<<<>>>>>>>>>>>>>
Sincere regards from C. L.
<<<<<<<<<<<<<>>>>>>>>>>>>>
Hi,
是在是在己方设备上发送"write no rsp”然后导致己方设备崩溃重启。BTSpy抓取的,是己方设备(发送write请求的设备)的trace
BR,
Treacy
Hi,
该结构体下没有.max_mtu_size的定义
所以我之前的定义没有问题(也就是说我是用如下的配置测出来的write的问题),定义如下
而我抓的BTSpy的log又分析不出问题。所以你们能用hci_audio_gateway的demo测试一下,确认一下这个问题吗
write的问题请问在跟进吗
Hi,
关于Write Command中Value长度的细节,我截图了Specs中的相关内容给您参考:
具体而言,它实际的长度会与Server端的对该Attr的设置有关。即您还需要结合对端设备的情况来考量。
至于程序崩溃重启的问题,我还是继续建议您使用JLink或者MiniProg等调试器来进行步进调试以分析原因。
<<<<<<<<<<<<<>>>>>>>>>>>>>
Sincere regards from C. L.
<<<<<<<<<<<<<>>>>>>>>>>>>>