CC2640: Sometime receive an unknown packet during pairing.

Hi Ricky,

Can you share the SDK version you are using? Do you have access to a BLE sniffer? If so, then could you take a log showcasing the device connection, pairing, and transmission of the unknown packet? The sniffer software should be able to parse and identify what the packet is and what may be causing the pairing failure. Is this behavior occurring on a single device or all devices with this firmware? Does it occur every time? Is it easy to reproduce?

Best Regards,

Jan

Hi Jan,

1.) We use Code Composer Studio 7.4.0 and CC2640R2 SDK 1.50.00.58.

2.) Yes.  Here are links.
No unknown packet: https://drive.google.com/file/d/159pVtrOtPjb9c111ZSLFvRfWu8nMMJHn/view?usp=sharing
Unknown packet: https://drive.google.com/file/d/1OGlt5WaW-X8LMYGqYtGKjneqrw5EjpcV/view?usp=sharing

3.) This happens on all devices with the CC2640 using the same FW.

4.) Yes and no.  There's no pattern to this behavior.  Sometimes it is tough to reproduce the issue, and then the issue always happens.  However, the issue started when I enabled pairing and pin code.  When pairing is disabled, then the issue never happens.

Hi Ricky,

Can you attach the files directly to your reply? We are not able to use external file hosting services.

Best Regards,

Jan

Hi Ricky,

Is there any update?

Best Regards,

Jan

Hi Jan,

Here are the files.

.no-unknown-pkt.psdunknown-pkt.psd

Thanks!

Hi Ricky,

Could you specify where in the log i can find the affected packet? Which is the packet number of the unknown packet in the unknown-pkt.psd log?

Best Regards,

Jan

Hi Jan,

I think there may be a miss communication.  The packet is an HCI packet, not a BLE packet.

without_unknown_packet.log

with_unknown_packet.log

The unknown packet can be seen in with_unknown_packet.log
1980/01/06 00:49:11 [P_UART] (DEBUG) HEX DUMP: 00 40 00 20 61 01 01 00 01 c9 01 10 01 c9 01 10
1980/01/06 00:49:11 [P_UART] (DEBUG) HEX DUMP: 01 c9 01 10 01 c9 01 10 01 c9 01 10 01 c9 01 10
1980/01/06 00:49:11 [P_UART] (DEBUG) HEX DUMP: 01 c9 01 10 01 c9 01 10 01 c9 01 10 01 c9 01 10
1980/01/06 00:49:11 [P_UART] (DEBUG) HEX DUMP: 01 c9 01 10 01 c9 01 10 3f c9 01 10 2d e9 f0 4f
1980/01/06 00:49:11 [P_UART] (DEBUG) HEX DUMP: 04 46 d1 48 00 21 2c 22 ad f1 14 0d 34 30 07 46
1980/01/06 00:49:11 [P_UART] (DEBUG) HEX DUMP: 0d f0 28 fd 00 20 03 90 01 20 04 90 20 78 a0 38
1980/01/06 00:49:11 [P_UART] (DEBUG) HEX DUMP: 00 f0 35 84 80 1e 00 f0 0a 84 0e 38 00 f0 04 ff
1980/01/06 00:49:11 [P_UART] (DEBUG) HEX DUMP: 08 0a 05 00 00 00 02 03 00

I can't find any information on an HCI packets starting with 0x00.

The original developers aren't around, so I don't know if they created a custom HCI packet, or it's a valid HCI packet that I can't find any information on.

Hi Ricky,

My sincerest apologies, I thought the issue was a bad BLE packet being received over the air. The first byte in an HCI transmission corresponds to the type of HCI packet type. There are four possible values for the packet type listed below:

0x01 - Command

0x02 - Asynchronous Data

0x03 - Synchronous Data

0x04 - Event

0 is not a pre-defined packet type, so it is very likely that command is a custom HCI command that was created during the development of your application. If this is the case, then you must ensure that the receiver of the HCI message is equipped to process the custom HCI message.

Best Regards,

Jan

Thanks Jan!

I'm having difficulties finding the custom HCI packet.  Do you have any suggestions to find it?

Hi Ricky,

If the HCI packet is a custom HCI packet written by the previous developer, then code handling the transmission and reception of the packet must be written. I would suggest looking into that area of the code to start.

Best Regards,

Jan