rfcomm cant reopen

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

cross mob
Anonymous
Not applicable

I'm trying to use rfcomm to communicate between a phone as a client and a BCM943341WCD1 board as the server, and it's possible to open an rfcomm connection once. But when the connection is closed, it's impossible to reopen it.

After I detect a close, I do the reopen procedure on the server side, including the code below, but it's impossible to reconnect.

Anybody know how to do it?

Magnus

    wiced_bt_rfcomm_create_connection( UUID_SERVCLASS_SERIAL_PORT,

                                       BT_RFCOMM_SERVER_APP_SCN,

                                       (wiced_bool_t)TRUE,

                                       BT_RFCOMM_SERVER_APP_MTU,

                                       NULL,

                                       &serverHandle,

                                       connection_cb );

    /* Set data callback RFCOMM */

    wiced_bt_rfcomm_set_data_callback(serverHandle, BTDriver::data_cb);

    /* Set event callback RFCOMM, and events to be notified of */

    wiced_bt_rfcomm_set_event_mask(serverHandle, BT_RFCOMM_SERVER_EVT_MASK);

    wiced_bt_rfcomm_set_event_callback(serverHandle, BTDriver::event_cb);

  /* Enable connectablity (use default connectablity window/interval) */

  int ret = wiced_bt_dev_set_connectability(BTM_CONNECTABLE, 0, 0);

  /* Enable discoverablity (use default discoverablity window/interval) */

  ret = wiced_bt_dev_set_discoverability(BTM_GENERAL_DISCOVERABLE, 0, 0);

0 Likes
1 Solution
Anonymous
Not applicable

I tried upgrading to 3.7.0 today, and after a few initial obstacles I can now verify that the problem is fixed. I can now reconnect without problems without the patch I had before.

Thanks!

View solution in original post

15 Replies
Anonymous
Not applicable

Some more info.

The original attempt was made with v3.1.2. But the behaviour is identical with 3.5.2.

I include some logging below, and the problem seems to be that the BT stack fails to handle some data that seems to come in after the RFCOMM connection is closed. This data is then misinterpreted as something else and the BT stack stops asking for more data.

The log output is not only Wiced logs, but shouldn't confuse things.

At 02:11:19.955, the stack asks for 1 byte, which almost immediately arrives. Then it asks for 4 bytes, which is already in the ring buffer. But after that, it never asks for any more data.

Any help with this appreciated.

Magnus

02:11:19.869 CHTask0: ===== logout =====

02:11:19.873 CHTask0: One wants to logout

02:11:19.873 CHTask0: Closing connection ch 20014728. CHTask 0

02:11:19.873 CHTask0: BTStream::close handle 0x2

02:11:19.873 CHTask0: flushData

02:11:19.873 CHTask0: rfcomm_write wrote 0 of 0

02:11:19.873 CHTask0: platform_uart_irq rx_size 1, rb_used 0

02:11:19.877 CHTask0: platform_uart_irq rx_size 0, rb_used 9

02:11:19.877 CHTask0: platform_uart_irq rx_size 0, rb_used 18

02:11:19.877 CHTask0: platform_uart_irq rx_size 0, rb_used 27

02:11:19.877 CHTask0: platform_uart_irq rx_size 0, rb_used 30

02:11:19.877 READ_THREAD: BT recv 1

02:11:19.881 READ_THREAD: 04

02:11:19.881 READ_THREAD: platform_uart_receive_bytes res 0

02:11:19.881 READ_THREAD: platform_uart_receive_bytes 2, timeout -1

02:11:19.881 READ_THREAD: BT recv 2

02:11:19.881 READ_THREAD: 13 05

02:11:19.881 READ_THREAD: platform_uart_receive_bytes res 0

02:11:19.881 READ_THREAD: platform_uart_receive_bytes 5, timeout -1

02:11:19.885 READ_THREAD: BT recv 5

02:11:19.885 READ_THREAD: 01 0b 00 02 00

02:11:19.885 READ_THREAD: platform_uart_receive_bytes res 0

02:11:19.885 READ_THREAD: platform_uart_receive_bytes 1, timeout -1

02:11:19.885 READ_THREAD: BT recv 1

02:11:19.885 READ_THREAD: 02

02:11:19.889 READ_THREAD: platform_uart_receive_bytes res 0

02:11:19.889 READ_THREAD: platform_uart_receive_bytes 4, timeout -1

02:11:19.889 READ_THREAD: BT recv 4

02:11:19.889 READ_THREAD: 0b 20 11 00

02:11:19.889 READ_THREAD: platform_uart_receive_bytes res 0

02:11:19.889 READ_THREAD: platform_uart_receive_bytes 17, timeout -1

02:11:19.893 READ_THREAD: BT recv 17

02:11:19.893 READ_THREAD: 0d 00 43 00 0b ef 13 08 08 00 10 07 2a 02 08 04 9a

02:11:19.893 READ_THREAD: platform_uart_receive_bytes res 0

02:11:19.897 HCISU: BT transmit 14

02:11:19.897 HCISU: 02 0b 20 09 00 05 00 4c 00 09 ff 01 01 5c

02:11:19.897 READ_THREAD: platform_uart_receive_bytes 1, timeout -1

02:11:19.901 CHTask0: platform_uart_tx_irq

02:11:19.901 CHTask0: receiveMoreData

02:11:19.908 CHTask0: rfcomm_server_evt_cback event event=0x80B8, handle 2

02:11:19.908 HCISU: BT transmit 13

02:11:19.908 HCISU: 02 0b 20 08 00 04 00 4c 00 09 53 01 d9

02:11:19.912 CHTask0: removed connection 2, ret 0

02:11:19.912 CHTask0: BTStream::close done

02:11:19.912 CHTask0: platform_uart_tx_irq

02:11:19.932 IDLE: platform_uart_irq rx_size 1, rb_used 0

02:11:19.932 IDLE: platform_uart_irq rx_size 0, rb_used 8

02:11:19.936 READ_THREAD: BT recv 1

02:11:19.936 READ_THREAD: 04

02:11:19.936 READ_THREAD: platform_uart_receive_bytes res 0

02:11:19.936 READ_THREAD: platform_uart_irq rx_size 0, rb_used 7

02:11:19.936 READ_THREAD: platform_uart_irq rx_size 0, rb_used 20

02:11:19.936 READ_THREAD: platform_uart_receive_bytes 2, timeout -1

02:11:19.940 READ_THREAD: BT recv 2

02:11:19.940 READ_THREAD: 13 05

02:11:19.940 READ_THREAD: platform_uart_receive_bytes res 0

02:11:19.940 READ_THREAD: platform_uart_receive_bytes 5, timeout -1

02:11:19.940 READ_THREAD: BT recv 5

02:11:19.940 READ_THREAD: 01 0b 00 02 00

02:11:19.944 READ_THREAD: platform_uart_receive_bytes res 0

02:11:19.944 READ_THREAD: platform_uart_receive_bytes 1, timeout -1

02:11:19.944 READ_THREAD: BT recv 1

02:11:19.944 READ_THREAD: 02

02:11:19.944 READ_THREAD: platform_uart_receive_bytes res 0

02:11:19.944 READ_THREAD: platform_uart_receive_bytes 4, timeout -1

02:11:19.948 READ_THREAD: BT recv 4

02:11:19.948 READ_THREAD: 0b 20 08 00

02:11:19.948 READ_THREAD: platform_uart_receive_bytes res 0

02:11:19.948 READ_THREAD: platform_uart_receive_bytes 8, timeout -1

02:11:19.948 READ_THREAD: BT recv 8

02:11:19.948 READ_THREAD: 04 00 43 00 09 73 01 f3

02:11:19.951 READ_THREAD: platform_uart_receive_bytes res 0

02:11:19.951 BTU: RFCOMM connection closed. handle 2

02:11:19.951 BTU: started server handle: 3

02:11:19.951 BTU: Set connectability 0

02:11:19.951 BTU: Set discoverability 0

02:11:19.951 BTU: Waiting for RFCOMM connection (scn=1)...

02:11:19.955 HCISU: BT transmit 13

02:11:19.955 HCISU: 02 0b 20 08 00 04 00 4c 00 01 53 01 9c

02:11:19.955 READ_THREAD: platform_uart_receive_bytes 1, timeout -1

02:11:19.955 IDLE: platform_uart_tx_irq

02:11:19.991 IDLE: platform_uart_irq rx_size 1, rb_used 0

02:11:19.991 IDLE: platform_uart_irq rx_size 0, rb_used 9

02:11:19.991 IDLE: platform_uart_irq rx_size 0, rb_used 17

02:11:19.995 IDLE: platform_uart_irq rx_size 0, rb_used 26

02:11:19.995 IDLE: platform_uart_irq rx_size 0, rb_used 35

02:11:19.995 IDLE: platform_uart_irq rx_size 0, rb_used 38

02:11:19.995 READ_THREAD: BT recv 1

02:11:19.995 READ_THREAD: 02

02:11:19.995 READ_THREAD: platform_uart_receive_bytes res 0

02:11:19.999 READ_THREAD: platform_uart_receive_bytes 4, timeout -1

02:11:19.999 READ_THREAD: BT recv 4

02:11:19.999 READ_THREAD: 0b 20 08 00

02:11:19.999 READ_THREAD: platform_uart_receive_bytes res 0

02:11:33.830 IDLE: platform_uart_irq rx_size 0, rb_used 33

02:11:33.834 IDLE: platform_uart_irq rx_size 0, rb_used 40

02:11:50.242 IDLE: platform_uart_irq rx_size 0, rb_used 40

02:11:50.242 IDLE: platform_uart_irq rx_size 0, rb_used 49

02:11:50.242 IDLE: platform_uart_irq rx_size 0, rb_used 53

02:11:55.250 IDLE: platform_uart_irq rx_size 0, rb_used 53

02:11:55.250 IDLE: platform_uart_irq rx_size 0, rb_used 62

02:11:55.250 IDLE: platform_uart_irq rx_size 0, rb_used 67

02:11:55.356 IDLE: platform_uart_irq rx_size 0, rb_used 67

02:11:55.356 IDLE: platform_uart_irq rx_size 0, rb_used 76

02:11:55.356 IDLE: platform_uart_irq rx_size 0, rb_used 80

03:12:00.356 IDLE: platform_uart_irq rx_size 0, rb_used 80

03:12:00.356 IDLE: platform_uart_irq rx_size 0, rb_used 89

03:12:00.356 IDLE: platform_uart_irq rx_size 0, rb_used 94

03:12:06.383 IDLE: platform_uart_irq rx_size 0, rb_used 94

0 Likes

Hi Magnus,

We are looking at this issue, kindly provide us time to investigate and provide you a solution

thnx

vik86

Hi Magnus,

we were not able to reproduce this in bt_dual_mode_server app, which is based on RFCOMM

And also while calling wiced_bt_rfcomm_create_connection, we need to pass bd_addr.

i.e

wiced_bt_rfcomm_create_connection( UUID_SERVCLASS_SERIAL_PORT, BT_RFCOMM_SERVER_APP_SCN, (wiced_bool_t)TRUE, BT_RFCOMM_SERVER_APP_MTU,

bd_addr, {-> instead of passing NULL}

&serverHandle,

connection_cb );

Could you verify this?

0 Likes
Anonymous
Not applicable

Hi, thanks for looking into it.

However, simply changing NULL to bd_addr (with a 6*0 BD ADDR) didn't change the behaviour for me.

I'll finish up another thing I'm working on right now, but then I'll try the sample snip and see if I can get it working. In that case, I should be able to isolate the cause.

0 Likes
Anonymous
Not applicable

Hi again.

I was able reproduce on a BCM943341WCD1 eval board using FreeRTOS and LwIP. I don't think LwIP is used though, but there's no BTE link library for other stacks so that's the only way I could compile it with FreeRTOS.

So, if I compile with the line below, I can pair and connect once to the rfcomm server, but after that, it's dead.

./make snip.bluetooth.bt_dualmode_server-BCM943341WCD1-FreeRTOS-LwIP-debug download

0 Likes
Anonymous
Not applicable

vik86

Any feedback on this one would be mostly appreciated. Can you reproduce it now? Any suggestions for workarounds?

0 Likes

sorry for delay, will get back to you once I verify it with your mentioned steps above.

0 Likes
Anonymous
Not applicable

vik86

When investigating another issue (BLE congestions was sometimes never resolved, sometimes the condition was resolved but stopped transmitting data anyway), I stumbled upon the mutex calls made to wiced_rtos.c wiced_rtos_lock_mutex and wiced_rtos_unlock_mutex.

It is in this call to lock_mutex that the BT thread gets stuck. But when I change the mutex into a recursive mutex, things get better. I also change the timeout from FOREVER to 10 sec, and that gives me a chance to make a debug log if it fails, which it does.

Anyway, it seems the ThreadX and FreeRTOS mutex implementations differ somewhat and it's this difference that is causing the stall.

ssharma​​

thnx mcmagnus​ , we wlll look at this.

0 Likes
Anonymous
Not applicable

I asked this question while Wiced was still owned by Bcm but didn't get any useful feedback.

Perhaps someone at Cypress can review the thread and share any insights?

Thanks.  /Magnus

0 Likes

I will ask around and see if anyone can shed some light on the ThreadX and FreeRTOS mutex implementation issues you've highlighted.

0 Likes

dkumar

I believe they fixed this on ThreadX, have you had a chance to try it on 3.7.0 SDK ?

Anonymous
Not applicable

It was never a problem in ThreadX, the problem was only seen in FreeRTOS, which is what we use. If you meant FreeRTOS, then I'll try 3.7.0.

0 Likes

vik86 wrote:

dkumar

I believe they fixed this on ThreadX, have you had a chance to try it on 3.7.0 SDK ?

Can you share what is exactly the fix on ThreadX?

I don't find any fix about ThreadX on 3.7.0 CHANGELOG.txt.

0 Likes
Anonymous
Not applicable

I tried upgrading to 3.7.0 today, and after a few initial obstacles I can now verify that the problem is fixed. I can now reconnect without problems without the patch I had before.

Thanks!