2 Replies Latest reply on Jan 23, 2020 9:21 AM by vibo_4627196

    Spurious wake up from Bluetooth on CYW20704

    vibo_4627196

      We have used CYW20704 BT module in our product and are using the wake on Bluetooth functionality of CYW20704. The waking up of the host (our product) works fine with Ubuntu (using 16.04), Windows 10 and Android 6.0.1 but has an issue with iOS. The issue reproduce-able with iphone 6S (running iOS 12.4.4) and with iPAD (running  iOS 13.2). Haven't test this is on other Operating systems other than listed here.

       

      The problem is that with iOS products, when we initiate bluetooth communication with our product in its standby state, the connect request wakes up the product but if the product goes in suspended state within 25 seconds, it wakes up spuriously for a Bluetooth Event which was not initiated by the iOS device. On our product we are using Linux 4.9 with Bluez 4.91 (it is bit old, but due to security certifications for our product, we haven't upgraded bluez version)

       

      Below is the extract from hcidump logs on our product -

      HCI sniffer - Bluetooth packet analyzer ver 1.29

      device: hci0 snap_len: 1028 filter: 0xffffffff

      > ACL data: handle 11 flags 0x02 dlen 12

          L2CAP(s): Connect req: psm 1 scid 0x0b08

      < ACL data: handle 11 flags 0x00 dlen 16

      < ACL data: handle 11 flags 0x00 dlen 23

      < HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2

      > HCI Event: Command Status (0x0f) plen 4

      > ACL data: handle 11 flags 0x02 dlen 16

          L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4

            MTU 256

      < ACL data: handle 11 flags 0x00 dlen 18

      > HCI Event: Mode Change (0x14) plen 6

      > HCI Event: Number of Completed Packets (0x13) plen 5

      > ACL data: handle 11 flags 0x02 dlen 29

          L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 15

            Success

            MTU 672 Mode 0x00 (Basic)

      > ACL data: handle 11 flags 0x02 dlen 23

          L2CAP(d): cid 0x0041 len 19 [psm 0]

      < ACL data: handle 11 flags 0x00 dlen 46

      > HCI Event: Number of Completed Packets (0x13) plen 5

      > ACL data: handle 11 flags 0x02 dlen 39

          L2CAP(d): cid 0x0041 len 35 [psm 0]

      < ACL data: handle 11 flags 0x00 dlen 33

      > ACL data: handle 11 flags 0x02 dlen 25

          L2CAP(d): cid 0x0041 len 21 [psm 0]

      < ACL data: handle 11 flags 0x00 dlen 33

      > HCI Event: Number of Completed Packets (0x13) plen 5

      > ACL data: handle 11 flags 0x02 dlen 12

          L2CAP(s): Disconn req: dcid 0x0041 scid 0x0b08

      < ACL data: handle 11 flags 0x00 dlen 12

      > HCI Event: Number of Completed Packets (0x13) plen 5

      < HCI Command: Write Scan Enable (0x03|0x001a) plen 1

      > HCI Event: Command Complete (0x0e) plen 4

      < HCI Command: Read Scan Enable (0x03|0x0019) plen 0

      > HCI Event: Command Complete (0x0e) plen 5

      < HCI Command: Write Class of Device (0x03|0x0024) plen 3

      > HCI Event: Command Complete (0x0e) plen 4

      > HCI Event: Mode Change (0x14) plen 6

      < HCI Command: Write Scan Enable (0x03|0x001a) plen 1

      > HCI Event: Command Complete (0x0e) plen 4

      < HCI Command: Read Scan Enable (0x03|0x0019) plen 0

      > HCI Event: Command Complete (0x0e) plen 5

      < HCI Command: Write Class of Device (0x03|0x0024) plen 3

      > HCI Event: Command Complete (0x0e) plen 4

       

      The Log statement in bold, italic, underlined is the events which is causing the spurious wake up. This event happens around 25 seconds after the previous wake up. If the product goes to standby within 25 seconds, it will be woken up due to this event. Any information on what would be causing this event will be helpful.