hello-client switch to slaves after smartphone connectes

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I build a application based on the hello-client that is checking some

environmental values and send some data to connected slaves. A user can change

some data with his smartphone. But if the smartphone is connected, the

hello-client can't write to the connected slave.

How can I switch back to the slave to send new data?

0 Likes
1 Solution
Anonymous
Not applicable

Hello.

We ran your code and found the same error.

Here's what we did:

1. Connect hello_sensor to your hello_client (connhandle : 0x41)

2. Connect 2nd hello_sensor to your hello_client (connhandle : 0x42)

The error happens because of the way connections are added to the conn mux and the way hello_client keeps track of those connections.

The hello_client adds a new connection to the mux by calling:

     blecm_AddConMux(con_index, con_handle, sizeof (hello_client_gatt_database), (void *)hello_client_gatt_database,

            &hello_client.dev_info[cm_index], &hello_client.smp_info[cm_index]);

and keeps track of them by storing the connection info in hello_client.dev_info

Notice how con_index is used to add new connection and how cm_index is used to index those connections in the dev_info array.

Those two numbers should match when you are adding a new connection. However, they don't in your hello_client.

From the code:

     con_index = connhandle - 0x40;

     cm_index = blecm_FindFreeConMux();

The original hello_client expects the connhandle from first connection to be 0x40.

The following is the debug trace from the original hello_client:

10:01:21 - con_handle: 64, con_index: 0

10:01:21 -

10:01:21 - &&&&&&&&&&&&&&&&&&& what is found cm_index: -1

10:01:21 - $$$$$$$$$$$$$$$$$$$ what is cm_index: 0

10:02:25 - con_handle: 65, con_index: 1

10:02:25 -

10:02:25 - &&&&&&&&&&&&&&&&&&& what is found cm_index: -1

10:02:25 - $$$$$$$$$$$$$$$$$$$ what is cm_index: 1

note 64 is 0x40. Notice how con_index and cm_index are matching?

Now for some reason, using your hello_client, the connhandle from the first connection is 0x41.

The following is the debug trace from your hello_client:

09:38:57 - con_handle: 65, con_index: 1

09:38:57 -

09:38:57 - &&&&&&&&&&&&&&&&&&& what is found cm_index: -1

09:38:57 - &&&&&&&&&&&&&&&&&&& what is cm_index: 0

09:39:31 - con_handle: 66, con_index: 2

09:39:31 -

09:39:31 - &&&&&&&&&&&&&&&&&&& what is found cm_index: -1

09:39:31 - &&&&&&&&&&&&&&&&&&& what is cm_index: 0

note 65 is 0x41. Notice the difference in con_index and cm_index?

Remember you are using con_index for adding new connections to con mux and cm_index to access dev_info from the app.

So the first connection gets saved in con mux with index 1 and the second connection gets saved with index 2.

But index 0 is still unused. So when you initialize cm_index with blecm_FindFreeConMux, you always get 0, since the method returns first unused index in con mux. So since cm_index is the same for both connections, you are overwriting the data in the array dev_info.

So when you loop through it, you only have the info about the latest device.

A simple solution that I found was to use cm_index when you are adding the new connection to con mux in connection_up callback.

      blecm_AddConMux(cm_index, con_handle, sizeof (hello_client_gatt_database), (void *)hello_client_gatt_database,

            &hello_client.dev_info[cm_index], &hello_client.smp_info[cm_index]);

Also in connection_down, you might want to change con_index like this:

     UINT32 con_index = blecm_FindConMux(con_handle);

With these changes I was able to get this result:

11:50:03 - hello_client_timeout sending 15 to:0041

11:50:03 -

11:50:03 - l2cap Tx:

11:50:03 - 41200800040004001202010f

11:50:03 - hello_client_timeout sending 15 to:0042

11:50:03 -

11:50:03 - l2cap Tx:

11:50:03 - 42200800040004001202010f

I don't know why the connhandle from the first connection is 0x41 from your code.

I'll ask the developers about that.

Does this solve your problem? Please let us know.

Thank you

James

View solution in original post

41 Replies
Anonymous
Not applicable

Hello.

We ran your code and found the same error.

Here's what we did:

1. Connect hello_sensor to your hello_client (connhandle : 0x41)

2. Connect 2nd hello_sensor to your hello_client (connhandle : 0x42)

The error happens because of the way connections are added to the conn mux and the way hello_client keeps track of those connections.

The hello_client adds a new connection to the mux by calling:

     blecm_AddConMux(con_index, con_handle, sizeof (hello_client_gatt_database), (void *)hello_client_gatt_database,

            &hello_client.dev_info[cm_index], &hello_client.smp_info[cm_index]);

and keeps track of them by storing the connection info in hello_client.dev_info

Notice how con_index is used to add new connection and how cm_index is used to index those connections in the dev_info array.

Those two numbers should match when you are adding a new connection. However, they don't in your hello_client.

From the code:

     con_index = connhandle - 0x40;

     cm_index = blecm_FindFreeConMux();

The original hello_client expects the connhandle from first connection to be 0x40.

The following is the debug trace from the original hello_client:

10:01:21 - con_handle: 64, con_index: 0

10:01:21 -

10:01:21 - &&&&&&&&&&&&&&&&&&& what is found cm_index: -1

10:01:21 - $$$$$$$$$$$$$$$$$$$ what is cm_index: 0

10:02:25 - con_handle: 65, con_index: 1

10:02:25 -

10:02:25 - &&&&&&&&&&&&&&&&&&& what is found cm_index: -1

10:02:25 - $$$$$$$$$$$$$$$$$$$ what is cm_index: 1

note 64 is 0x40. Notice how con_index and cm_index are matching?

Now for some reason, using your hello_client, the connhandle from the first connection is 0x41.

The following is the debug trace from your hello_client:

09:38:57 - con_handle: 65, con_index: 1

09:38:57 -

09:38:57 - &&&&&&&&&&&&&&&&&&& what is found cm_index: -1

09:38:57 - &&&&&&&&&&&&&&&&&&& what is cm_index: 0

09:39:31 - con_handle: 66, con_index: 2

09:39:31 -

09:39:31 - &&&&&&&&&&&&&&&&&&& what is found cm_index: -1

09:39:31 - &&&&&&&&&&&&&&&&&&& what is cm_index: 0

note 65 is 0x41. Notice the difference in con_index and cm_index?

Remember you are using con_index for adding new connections to con mux and cm_index to access dev_info from the app.

So the first connection gets saved in con mux with index 1 and the second connection gets saved with index 2.

But index 0 is still unused. So when you initialize cm_index with blecm_FindFreeConMux, you always get 0, since the method returns first unused index in con mux. So since cm_index is the same for both connections, you are overwriting the data in the array dev_info.

So when you loop through it, you only have the info about the latest device.

A simple solution that I found was to use cm_index when you are adding the new connection to con mux in connection_up callback.

      blecm_AddConMux(cm_index, con_handle, sizeof (hello_client_gatt_database), (void *)hello_client_gatt_database,

            &hello_client.dev_info[cm_index], &hello_client.smp_info[cm_index]);

Also in connection_down, you might want to change con_index like this:

     UINT32 con_index = blecm_FindConMux(con_handle);

With these changes I was able to get this result:

11:50:03 - hello_client_timeout sending 15 to:0041

11:50:03 -

11:50:03 - l2cap Tx:

11:50:03 - 41200800040004001202010f

11:50:03 - hello_client_timeout sending 15 to:0042

11:50:03 -

11:50:03 - l2cap Tx:

11:50:03 - 42200800040004001202010f

I don't know why the connhandle from the first connection is 0x41 from your code.

I'll ask the developers about that.

Does this solve your problem? Please let us know.

Thank you

James

Anonymous
Not applicable

Hi James,

Thank you very much.

It seems your solution works.

0 Likes