• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 51 subscribers
  • Views 1525 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652R: CRC error sniffing BLE data packets

Daniel Brox
Prodigy 50 points
Part Number: CC2652R
Other Parts Discussed in Thread: CC2540EMK-USB,

Hi,

Testing audio data transfer ota with two BLE devices. I can hear the audio transfer is correct by listening to the audio output of one device, and the C2652R1 packet sniffer.exe displays a CONNECT_REQ followed by initiation / data transfer events in wireshark. However, the 'received write command' packets that appear in wireshark when audio transfer is occurring show a CRC error, and no nonzero data is displayed (data transfer has been set to occur at 1M). How can I fix this error to correctly display the data transfer? Using the TI sniffer, I noticed in the Wireshark output of a data link that the 'received write command' shows frame length 304 -does this make sense for an exchanged MTU of 247? If the exchanged MTU is set incorrectly for the data being sent (e.g. too small) could this cause the problem shown? I'm expecting to see non-empty data transfers via notification every connection event (~25ms) consisting of >200bytes while audio is being transferred.

  • 0
    TI__Expert 4435 points

    Hi Daniel,

    Can you provide the sniffer log you are referring to please? I want to take a look at the packets where this CRC error is occurring. Thanks!

    Best Regards,

    Jenny

  • 0 in reply to Jenny T
    Prodigy 50 points

    Sorry, there was incorrect information in my previous post.  The TI sniffer shows data packets with a 'CRC unchecked, not all data available' message, while a Nordic BLE sniffer (for comparison) shows a CRC error.  In both cases, sniffers do not appear to be showing all data packets, which I expect to be showing for each connection event, and which appear to be sent ota as verified by the fact transmission of audio data across the BLE connection between two BLE devices can be heard correctly on the receiver side.  I notice the exchange MTU request at the beginning of the connection shows an MTU of 247 - if this is configured incorrectly in device firmware could this be causing a problem with sniffing data packets?

    Here is the TI sniffer output in Wireshark:

    www.dropbox.com/.../TIdevice_connect.pcapng

    Here is the Nordic sniffer output in Wireshark:

    www.dropbox.com/.../SnifferV3.pcapng

  • 0 in reply to Daniel Brox
    TI__Expert 4435 points

    Hi Daniel,

    I apologize for the delayed response. After reviewing the sniffers, I noticed that both BLE devices (Master and Slave) seem to have Cypress in the MAC address. I wanted to verify if the sniffer captures were for two BLE devices running on Cypress MCUs.

    Best Regards,

    Jenny

  • 0 in reply to Jenny T
    Prodigy 50 points

    Yes.  The two BLE devices run on Cypress MCUs.  How can I sniff the data packets correctly?  I was told the C2652R1 is compatible with 2M PHY before purchase.

  • 0 in reply to Daniel Brox
    TI__Expert 4435 points

    Hi Daniel,

    You are correct, there shouldn't be any issues using the CC2652R1 as a sniffer for the Cypress MCUs as there shouldn't be any filtering logic added to the sniffer FW. However, the plugins installed for TI vs Nordic may be different in how they display the CRC error which is why you're seeing the TI sniffer display CRC unchecked while Nordic displays CRC error. 

    Since the devices are running Cypress specific code, and both sniffers are showing CRC errors, it will be hard to offer solutions on how to debug this. To further narrow down if it's sniffer related or code related, is it possible to run an Out of Box unmodified BLE examples on the Cypress MCUs and use both the Nordic and TI sniffers again to see if there are any errors in the sniffed packets?

    Best Regards,

    Jenny

  • 0 in reply to Jenny T
    Prodigy 50 points

    Hi,

    I tried sniffing a connection between and Android phone and a Fitbit watch (address f5:78:bc:ec:14:f2) using the TI CC2652R1 and Nordic nRF52 DK sniffers (attached below).  In both cases, a CONNECT_REQ is observed (lines 11635 and 25345), but the exchange MTU request and following data packets associated with the connection are not correctly sniffed.  I noticed this problem with the TI sniffer before when I tried to sniff a data link between Cypress devices at 2M (switching Cypress devices to 1M resulted in the previous connection link Wireshark data I sent you).  How can I use the TI CC2652R1 to sniff the BLE connection between an Android phone and Fitbit watch (I was informed it should be able to handle sniffing 2M data links)?

    TI sniffer:

    www.dropbox.com/.../TI_sniffer_Fitbit.pcapng

    Nordic sniffer:

    www.dropbox.com/.../Nordic_sniffer_Fitbit.pcapng

  • 0 in reply to Daniel Brox
    TI__Expert 4435 points

    Hi Daniel,

    Thanks for performing these additional tests. Based on the CONNECT_REQ packet sent from 43:07:d0:52:a5:d3 to the Fitbit (f5:78:bc:ec:14:f2), to verify, is the initiator address in SmartRF Packet Sniffer 2  set to 43:07:d0:52:a5:d3? More information on why this is needed can be found in the Configuration for Bluetooth Low Energy Section of the SmartRF Packet Sniffer 2 User's Guide. 

    If the initiator address is already being set properly, two additional points could cause the sniffer to not follow the connection properly:

    - The sniffer is only capable of sniffing one BLE channel. If the connection is formed on a different channel and not the one specified in the Radio Options, it will not follow the connection. So it may either take a few runs of the connection to successfully follow the connection or a workaround is to change the advertisement parameters to advertise on one channel only (the channel you are sniffing).

    - In addition, I believe it is not capable of sniffing BT5 features as it will filter out these

    Best Regards,

    Jenny

  • 0 in reply to Jenny T
    Prodigy 50 points

    Hi,

    This is the information I was given from a previous TI support request:

    "CC2540EMK-USB can only sniff Bluetooth 4.x packets. If you don't use BLE 5.x features (such as DLE, Coded PHYs, 2M PHY, etc.) you should be fine. However, if you need these features, I would recommend going for PACKET-SNIFFER-2 (with CC2652R)"
    Are you saying the CC2652R1 is incapable of sniffing 2Mbps BLE?
    In response to your first question, I don't think the initiator was set correctly (initiator address seems to be dynamic), but when I had 2Mbps enabled on Cypress devices, I saw the same absence of data packets after the CONNECT_REQ, so if BT5 is filtered out, setting this correctly won't solve the problem.
  • 0 in reply to Daniel Brox
    TI__Expert 4435 points

    Hi Daniel,

    I apologize for the confusion. The SmartRF Packet Sniffer 2 does not support Bluetooth Core Spec 5.

    In addition, I agree with your comment on the initiator address being dynamic for the second test case. In addition, the packets between the phone and Fitbit might not be an accurate test for the SmartRF Packet Sniffer 2 as they will most likely be encrypted packets being exchanged.

    For a more robust sniffer that can follow encrypted packets and Bluetooth Core Spec 5, I recommend using the Ellysis or Frontier if possible.

    Best Regards,

    Jenny