cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Bluetooth

YaTr_3516311
New Contributor II

Hi

我在测试write命令的时候,发现如果写很大的数据,比如100byte的话,多次wirte会导致cybt343026-01重启。以下是我用64bytes进行多次测试的情况

1. 多次发送后会出现失败的情况(我大概测试了7次左右)。请问该如何解决这个问题

pastedImage_0.png

2. 出现1的情况后,我想抓用spy抓log给你们分析,但是发现value里写入的64bytes的数据,但是spy收到的数据长度是33 byte?工具是会限定数据长度吗?然后就没有重现1的现象

pastedImage_1.png

3. 所以wirte no rsp支持写多大的数据呢

0 Likes
1 Solution
Charles_Lai
Moderator
Moderator

Hi,

关于Write Command中Value长度的细节,我截图了Specs中的相关内容给您参考:

pastedImage_0.png

具体而言,它实际的长度会与Server端的对该Attr的设置有关。即您还需要结合对端设备的情况来考量。

至于程序崩溃重启的问题,我还是继续建议您使用JLink或者MiniProg等调试器来进行步进调试以分析原因。

<<<<<<<<<<<<<>>>>>>>>>>>>>

Sincere regards from​ C. L.

<<<<<<<<<<<<<>>>>>>>>>>>>>

View solution in original post

0 Likes
9 Replies
Charles_Lai
Moderator
Moderator

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.

<<<<<<<<<<<<<>>>>>>>>>>>>>

0 Likes
YaTr_3516311
New Contributor II

Hi,

1. 我看了一下我这边测试的时候的代码,如下

我这边是用的CYW20706A2.也就是说没有设置max_mtu_size的值,那么该种情况下的默认值是多少?23吗

2. 按照您的解释,我是不是应该做如下改动?

期待您的回复

BR,

Treacy

0 Likes
Charles_Lai
Moderator
Moderator

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.

<<<<<<<<<<<<<>>>>>>>>>>>>>

0 Likes
YaTr_3516311
New Contributor II

Hi,

现在我的配置如下,请看看是够有问题。我会用这个参数进行测试。

0 Likes
Charles_Lai
Moderator
Moderator

Hi,

您这些参数是没有问题的。

另外如果使用了BTSpy后没有复现这个现象,可能是插入的额外的输出缓解了执行的频度,降低了系统各部分相互影响的可能。

此外,需要和您确认一下,您是在己方设备上发送"write no rsp”然后导致己方设备崩溃重启,还是对方设备在频繁接收请求后崩溃重启?并且您BTSpy抓取的,是己方设备(发送write请求的设备)的trace,还是对方设备(接收write请求的设备)的trace?

<<<<<<<<<<<<<>>>>>>>>>>>>>

Sincere regards from C. L.

<<<<<<<<<<<<<>>>>>>>>>>>>>

0 Likes
YaTr_3516311
New Contributor II

Hi,

是在是在己方设备上发送"write no rsp”然后导致己方设备崩溃重启。BTSpy抓取的,是己方设备(发送write请求的设备)的trace

BR,

Treacy

0 Likes
YaTr_3516311
New Contributor II

Hi,

该结构体下没有.max_mtu_size的定义

pastedImage_0.png

所以我之前的定义没有问题(也就是说我是用如下的配置测出来的write的问题),定义如下

pastedImage_1.png

pastedImage_2.png

而我抓的BTSpy的log又分析不出问题。所以你们能用hci_audio_gateway的demo测试一下,确认一下这个问题吗

0 Likes
YaTr_3516311
New Contributor II

write的问题请问在跟进吗

0 Likes
Charles_Lai
Moderator
Moderator

Hi,

关于Write Command中Value长度的细节,我截图了Specs中的相关内容给您参考:

pastedImage_0.png

具体而言,它实际的长度会与Server端的对该Attr的设置有关。即您还需要结合对端设备的情况来考量。

至于程序崩溃重启的问题,我还是继续建议您使用JLink或者MiniProg等调试器来进行步进调试以分析原因。

<<<<<<<<<<<<<>>>>>>>>>>>>>

Sincere regards from​ C. L.

<<<<<<<<<<<<<>>>>>>>>>>>>>

View solution in original post

0 Likes