Learn MoreFAQsTutorials

7 posts / 0 new
Last post
Sergei Bezroukov
Offline
Last seen: 10 hours 11 min ago
Joined: 2020-06-25 00:28
Connection drops

Hi there,

I am experimenting with a pair of DA14531 TINY modules connected to a computer via a 2-wire UART and USB/UART converter on CP2104 by using CodeLess firmware image codeless_531_standalone_set_two.hex. Establishing a connection between them works as described in Section 3.3 of  UM-B-140. But the probelm is that the modules drop the  connection after about 3 minutes. Is it possible to fix it so that the connection will remain active indefinitely?

Two other precompiled firmware images (codeless_531_standalone.hex and codeless_531_datapump.hex) are free of this disadvantage, but I need I2C support. I recompiled the standalone_set_two project from source, but it still drops connection after 2-3 minutes. Same happens if I recompile SET ONE firmware by adding I2C feature to it. Dialog team - please advise how to fix this.

 

PM_Dialog
Offline
Last seen: 20 hours 34 min ago
Staff
Joined: 2018-02-08 11:03
Hi Sergei Bezroukov,

Hi Sergei Bezroukov,

Thanks for your question.

>>> But the probelm is that the modules drop the  connection after about 3 minutes.

Can you please provide further details on this? When the connection drops? Are you sending any specific AT command? Can you please run it in debug mode?

>>>I2C support

Do you mean that there is an I2C interface connected to the TINE module, and your requirement is to read and transmit the I2C data?

I would recommend running the project in debug mode and check if it gets stuck into an assertion NMI etc.

Thanks, PM_Dialog

Sergei Bezroukov
Offline
Last seen: 10 hours 11 min ago
Joined: 2020-06-25 00:28
Thanks for the prompt

Thanks for the prompt response!

I2C has nothing to do with the issue, since so far I even do not issue any I2C command to the module. Also, it has no slave connected to it. The only module pins I use are P0_5 and P0_6 to connect it to external USB-UART converter.

I use Codeless SDK 6.380.10.4 with a free version of Keil v5.27.1.0 and commented out some AT commands in file user_at_command.h (see attached) to bring the codeless_stand_alone image under 32K limit. Following your advise I ran it in debug under Segger J-Link debugger. Right after starting the code I give to it AT+SLEEP=0 command, the module responded with OK and +AWAKE on the next line. Then I use Cypress CySmart tool along with their dongle as a central device to connect to the TINY module. Upon establishing the connection the module responded with +CONNECTED (in TeraTerm) and I can explore its services and attributes in CySmart used as BLE scanner tool. At this point everything works fine as expected - I can see the module's characteristics outlined in the manuals. Then I leave the module idling in the connection mode, that is issue no commands from TeraTerm and also no command over Bluetooth from CySmart. The connection is dropped after ca. 3 min as I described before. The debugger does not show me anyhing suspicious, definitely no NMI, actually it does not show anything, just runs the module code. The TeraTerm reports +READY and CySmart reports connection drop.

If you unaware with CySmart, I did the same experiment by establishing a Bluetooth connection with a pair of 531 TINY modules. One of them runs pre-compiled image (does not matter which one), the other modules runs my compiled image. The same connection drop happens after 3 min. However, if both modules run pre-compiled datapump or standalone images (by pre-compiled I mean the images provided in SmartBond Flash Programmer) tool, then no connection drop is experienced. But once one of the moduled is loaded with pre-compiled standlone set two, the connection drop happens. So, something is wrong with pre-compiled set-two image and with the SDK source code.

I wrote about I2C only because I need that option. So far I even did not try how it works, so the problem is definitely not related to I2C.

Attachment: 
PM_Dialog
Offline
Last seen: 20 hours 34 min ago
Staff
Joined: 2018-02-08 11:03
Hi Sergei Bezroukov,

Hi Sergei Bezroukov,

Since the application code does not stuck anywhere (NMI /  WDOG / assertion) , then it would be very helpful to share a sniffer log in order to understand what is happening over the air.

Would it be possible to use a BLE sniffer tool and share an sniffer capture?

Do you have a custom board, or you are using any of or DKs? Additionally, if you are using sleep mode, then you should use 4 UART signals (URX/UTX/RTS/CTS).

Thanks, PM_Dialog

Sergei Bezroukov
Offline
Last seen: 10 hours 11 min ago
Joined: 2020-06-25 00:28
Here you go. The attached

Here you go. The attached archive has a photo of my hardware (just DA14531 module and CP2104 USB-UART) and the BLE events Log. The Log shows that the 531 issued connection timeout 3 minutes after connection establishment (the last 3 records). I do not use SLEEP mode.

Attachment: 
PM_Dialog
Offline
Last seen: 20 hours 34 min ago
Staff
Joined: 2018-02-08 11:03
Hi Sergei Bezroukov,

Hi Sergei Bezroukov,

In the attached log, the disconnection reason is the connection timeout. According to Bluetooth LL core specifications, the Connection Timeout error code indicates that the link supervision timeout has expired for a given connection. The supervision timeout is set in the user_connection_param_conf structure.

Can please also indicate if the device starts advertising again after the disconnection? You can add a break point in the disconnection callback - user_on_disconnect() – and check the disconnection reason as well. Please see  gapc_disconnect_ind structure.

Thanks, PM_Dialog

Sergei Bezroukov
Offline
Last seen: 10 hours 11 min ago
Joined: 2020-06-25 00:28
Yes, after dropping the

Yes, after dropping the connection the DA device starts advertizing again. You are right: the Link supervision is expired because DA14531 stopped responding to connection events.

I created a special app by using Silicon Labs Simplicity Studio and their Thunderboard Sense 2 board as Central that just connects to DA14531 and does nothing after that while keeping the connection active. In the attached archive there are two images provided by Simplicity Studio Network Analyzer. On those images the device 90:FD:9F:7B:86:16 is my Central and DA:E4:D9:A6:F6:E9 is DA14531. On image named  Connection_parameters you can see that DA14531 requested to set Connection latency 5 and Supervision Timeout 1250ms, which were accepted by the client (see Events Detail window). Then on image Log2 you see that DA14531 works according to the Connection Latency by not responding to 5 consequtive connection intervals in series. But after 138sec in this case it was a longer series of not responded packets which caused Superivision timeout at Central. I also see this reason (Error 0x208) on Tera-Term output from my central device on the 3rd image.

From these logs it follows that after some time (2-3min) DA14531 stops responding to connection events for no reason. So, why don't you just fix your software. Such behavior is definitely a bug. You can easily convince yourself in that by compiling and loading your provided source code into two modules or dev boards.