1 2 Previous Next 15 Replies Latest reply on Oct 4, 2016 10:23 AM by magnusb

    rfcomm cant reopen

    mcmagnus

      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);

        • 1. Re: rfcomm cant reopen
          mcmagnus

          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

          • 2. Re: rfcomm cant reopen
            vikr

            Hi Magnus,

             

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

             

            thnx

            vik86

            • 3. Re: rfcomm cant reopen
              vikr

              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?

              • 4. Re: rfcomm cant reopen
                mcmagnus

                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.

                • 5. Re: rfcomm cant reopen
                  mcmagnus

                  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

                  • 6. Re: rfcomm cant reopen
                    mcmagnus

                    vikr

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

                    • 7. Re: rfcomm cant reopen
                      vikr

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

                      • 8. Re: rfcomm cant reopen
                        mcmagnus

                        vikr

                        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.

                        1 of 1 people found this helpful
                        • 9. Re: rfcomm cant reopen
                          vikr

                          ssharma

                           

                          thnx mcmagnus , we wlll look at this.

                          • 10. Re: rfcomm cant reopen
                            magnusb

                            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

                            • 11. Re: rfcomm cant reopen
                              mifo

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

                              • 12. Re: rfcomm cant reopen
                                vikr

                                dhak

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

                                2 of 2 people found this helpful
                                • 13. Re: rfcomm cant reopen
                                  magnusb

                                  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.

                                  • 14. Re: rfcomm cant reopen
                                    axel.lin_1746341

                                    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.

                                    1 2 Previous Next