DA14580_DSPS resets when receiving l2cap packet divided in BT fragments.

2 months ago

Hi Magnus Lö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

• Log inorregisterto post comments

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.

As I wrote I am using a PC as central device with our own written program when the reset occur. The central device SW is written for many platforms so we can run it from mobiles or iPads. When running it from a mobile or iPads we don’t see the reset and I think that is because they don’t divide up the l2cap header into BT frames (see picture from first comment), but the PC does.

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.

Anyway, even if it against the protocol the DA14580 should not reset, it should be handle as an error, not a reset.

The second question was if I could prevent this reset in any way.

Hopefully you could test to send a l2cap layer data with the l2cap header divided up.

Best regards

Magnus Lövdahl

• Log inorregisterto post comments

2 months ago

Hi Magnus Lö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.

Can I ask if it is an existing or upcoming product based on 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.

//www.xmece.com/亚博电竞菠菜products/connectivity/bluetooth-low-energy/products/da14531

There is a DA14531 module too, namely DA14531 SmartBond TINY™ Module!

DSPS is also available for DA14531:

//www.xmece.com/products/dialog-serial-port-service-dsps

Thanks, PM_Dialog

• Log inorregisterto post comments

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.

This is what it is pointing at and also map file info from addresses

R0 = 0x00082273

rwip_heap_env_ret 0x00080f74 Data 1036

rwip_heap_msg_ret 0x00081380 Data 4108

dev_bdaddr 0x0008238c Data 6

sys_startup_flag 0x00082392 Data 1

R1 = 0x00083000

diss_state 0x00082426 Data 1

descript 0x00082a20 Data 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 Code

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 Thumb Code

PSR = 0x21000000

Best regards

Magnus

Attachment	Size
dsps_log.zip	7.74 KB

• Log inorregisterto post comments

2 months ago

Hi Magnus Lö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

• Log inorregisterto post comments

2 months ago

Hello,

I am truly glad you trying to help me.

Best regards

Magnus

• Log inorregisterto post comments

2 months ago

Hi Magnus,

We have taken this offline from the forum, so someone from Dialog will reach out to you directly at your registered email address.

Thanks, PM_Dialog

• Log inorregisterto post comments