2 months ago
DA14580_DSPS resets when receiving l2cap packet divided in BT fragments.
Posted bymagnus.lovdahl…25 points 7 repliesHello
I have an issue where the DA14580 resets when receiving a l2cap data that is divided into fragments. The first frame is just a part of the l2cap header and the second part is the rest of the header and the attribute protocol data. See picture. I am not sure that is according to BT protocol? Anyway the DA14580 should not reset.
DA14580充当外设角色，并且我使用PC上的BT芯片作为中央的PC程序。
Attached is a Sodera LE BT sniffer trace showing the BT traffic.
Is there anything I can do in the DA14580_DSPS software to avoid a reset for this?
Is it according to specification to send l2cap fragment data in this way?
Best regards
Magnus Lövdahl
| Attachment | Size |
|---|---|
| DA14580 resets.png | 112.25 KB. |
2 months ago
Hello and thanks for the reply,
Yes there are small changes to DSPS project(v_5.150.2), but I don’t think that affect this issue.
I don’t have the possibility to use your SPS device as central so I can’t test that.
正如我在重置发生的情况下写下我正在使用PC作为中央设备。中央设备SW是为许多平台编写的，所以我们可以从Mobiles或iPad运行它。从移动或iPad运行时，我们没有看到重置，我认为这是因为它们不会将L2CAP标题分为BT帧（请参阅第一次评论的图片），但PC确实如此。
I think the DSPS project(v_5.150.2) resets because of the small BT frame where the l2cap header is divided up. I am not sure if it is legal to do that according to BT protocol. That was one of the questions I had.
无论如何，即使它反对协议DA14580不应重置，它应该处理为错误，而不是重置。
第二个问题是，如果我可以以任何方式阻止这种重置。
希望您可以测试使用L2CAP标题划分的L2CAP层数据。
Best regards
Magnus Lövdahl
2 months ago
嗨magnuslövdahl，
Thanks for your comment. Would it be possible to attach the whole sniffer so that we can go thought it?
You mentioned that the DA14580 resets. Can you please run it in debug mode and check if the code freezes into an assertion, NMI or the WDOG expires? I would like to check what could be the reset of the reset. I assume that the DA4580 is booting from flash and so after the reset it starts adverting immediately.
我可以问它是否是基于DA14580的现有或即将推出的产品？
if you are starting a new design, we would strongly recommend moving into DA14531 or DA14585/586 products and SDK6.0.14, as it is much more improved. We have a lot of code examples and improved documentation, and there is also software roadmap support. There is not any software roadmap support for DA14580 product family and SDK5.
https://www.dialog-seminile.com/produ亚博电竞菠菜cts/connectivity/bluetooth-low-energy/products/da14531.
There is a DA14531 module too, namely DA14531 SmartBond TINY™ Module!
DSP也可用于DA14531：
//www.xmece.com/products/dialog-serial-port-service-dsps
Thanks, PM_Dialog
2 months ago
Hello,
This is an existing product that have been used with mobil and tablets for a while. We are in a phase where we plan to release our “central device” SW also for a PC. It is when we use the PC a central we see the issues.
Attached is a part of sniffer file with the issue.
Let me explain it a little. We are in a streaming mode reading all lot of data from the micro connected via UART to the da14580 that send data via BT to the PC. Sometimes the PC acknowledge the transfer by sending data in the other direction. It is during one of these the PC divide up the l2cap header into one small BT fragment follow by 27 bytes fragments. The DA14580 crash.
The error occurs at frame number 184681. The PC sends out a l2cap frame. 5byte “start” frame followed by 27 byte “continuation” BT frame and DA14580 crash.
In the beginning of the log at frame number 184420 the PC sends out a correct l2cap frame. 27byte “start” frame followed by 27 byte “continuation” BT frame.
I don’t have the possibility to debug the da14580 with an emulator connected, so I am sending out UART data from the HardFault_HandlerC when the crash occur.
这是它指向的，也可以从地址映射文件信息
R0 = 0x00082273
RWIP_HEAP_ENV_RET 0x00080F74数据1036
RWIP_HEAP_MSG_RET 0x00081380数据4108
dev_bdaddr 0x0008238c Data 6
sys_startup_flag 0x00082392数据1
R1 = 0x00083000.
diss_state 0x00082426 Data 1
Descript 0x00082A20数据1502
__Vectors 0x20000000 Data 4
__Vectors_End 0x200000a0 Data 0
R2 = 0x00000052
R3 = 0x00000000
R12 = 0x0000052.
LR = 0x00031adb
l2cc_pdu_pack 0x0003164d Thumb Code
l2cc_pdu_unpack 0x000318f3 Thumb Code
l2cc_detect_dest 0x00031b2d thumb代码
smpc_check_param 0x00031b95 Thumb Code
PC = 0x00033b36
__aeabi_memcpy4 0x00033b21 Thumb Code
__aeabi_memcpy8 0x00033b21 Thumb Code
__aeabi_memset 0x00033b45 Thumb Code
__aeabi_memset4 0x00033b45拇指代码
PSR = 0x21000000
Best regards
Magnus
| Attachment | Size |
|---|---|
| dsps_log.zip. | 7.74 KB |
2 months ago
嗨magnuslövdahl，
Thanks for the issue description and for attaching a part of the Sniffer log. Let me check this and I'll get back to you. Probably I need to escalate this to the Team internally to check it out.
Thanks, PM_Dialog
2 months ago
嗨magnuslövdahl，
谢谢你的帖子。你能请注明ate if you are using the DSPS (sps_device) as provided by Dialog or have you done any modification in the source code? Additionally, what is the Central device that you are using? Can you replicate this with the sps_host application?
Thanks, PM_Dialog