在我们的自定义个人资料中，我们有一个由客户端/中央设备写入空中的特征。此特性在user_custs1_def.h中定义，以具有254的char_len（它是它应该是最大的大小）。在测试中，我们发现只要新的写入值的长度等于或短于上一个写入值，那么一切都正常工作。但是如果新值比以前写入的值长（即使新值仍然短于254的初始CHAR_LEN），则写入失败，系统开始运行不规定。例如，在更长的写入该特征之后，可以不再读取空气并且与客户端的连接变得不稳定。
看来在写入较长的字符串时，从不调用Custs1_task.c中的Gattc_Write_Req_ind_Handler（）函数，因此在代码中的这一点之前发生问题。
How can we implement the desired function? That is, a writable characteristic that can take any value from the client (up to 254 bytes), regardless of the current contents of that characteristic?
设备：
嗨米克伍德，
它似乎将更大的值写入特征，而不是先前写入的值，这不是问题，我无法复制它。您可以看看DSP应用程序，在DSP中我们可以在DSP中编写247字节的数据>，您可以拥有您想要的功能，因此请检查该项目中的特征是如何实现的。
谢谢，PM_DIALOG.
你好pm_dialog，
谢谢你的回应。我有一些额外的information. My initial conclusion on the problem was incorrect; it is not writes that are longer than previous writes that cause the issue. Rather, it is writes that are longer than (MTU - 3) bytes, which require the Write Long Characteristic Value procedure (Bluetooth spec 5.0 Vol 3 Part G section 4.9.4).
我从显示问题的OTA捕获文件中附加了一个屏幕截图。DA14585是从属（GATT Server）设备。目标特性具有处理53.在连接和发现之后，我将简短的（长度小于MTU - 3）值写入成功的特性（参见帧4468和4473）。我读回正确的值（框架6926和6932）。然后我尝试编写一个值为21字节的值（超过MTU - 3）。GATT客户端发送准备写入请求（帧7334，突出显示的帧），并且没有从DA14585的响应。奴隶现在被破坏了，没有反应。
我尝试将目标特征权限设置为write_req和write_command。附加的捕获是使用Write_Req权限。使用Write_Command，GATT客户端不会让我向特征写一个长值（它抱怨糟糕的参数）。
所以我现在的问题是，为什么写的长度特征值过程不起作用？为什么da14585没有准备写回复响应？我是否需要做任何特殊的东西来支持从GATT服务器端进行准备写/执行写序列？
Thanks for your help!
我更新到SDK 6.0.10.511;the problem with Write Long Characteristic Value persists. The device fails to respond to a Prepare Write Request from the central, and the device is unresponsive until disconnect/reconnect.
嗨米克伍德，
In case you don’t use or you don’t want to MTU exchange, you should implement the Write Long Characteristic Value as the implementation in the ble_app_peripheral example of the SDK. Please, take a look at this example of the SDK. If the length of the characteristic value to be written is greater than 20 bytes, then the user_svc1_long_val_att_info_req_handler() in the user_catch_rest_hndl() function will be triggered. If the length is less than 20 bytes the user_svc1_long_val_wr_ind_handler () will be executed. So, if you want to send more than 20 bytes without MTU exchange, you should do the same implementation as in the user_svc1_long_val_att_info_req_handler() function of the ble_app_peripheral example. Since you do that, the master will send a “Prepare Write Request” and the slave will response with a “Prepare Write Response”. Otherwise, if you want to do a simple write request and send more than 20 bytes, you should increase the MTU size.
谢谢，PM_DIALOG.
谢谢pm_dialog为此信息！我已经在建议时实现了ATT_INFO_REQ_HANDLER代码，这已经解决了写入长度特征值问题。在收到执行写命令后仍会调用WR_IND_HANDLLer;这是预期的和首选行为。
我从来没有猜到Att_Info_req_handler是制作写作长特征工作的代码。甚至在BLE_APP_PERITEATAL应用程序中看到代码，我就不会在此和准备写/执行写序列之间进行连接。我无法在对话框或riviera波浪文档中的任何位置找到文档。我希望有些这些更晦涩的回调有更好的文档。
嗨米克伍德，
Glad you figured your issue out.
谢谢，PM_DIALOG.