Malformed Bluetooth Low Energy CRTP packets

[ataffanel]

Discussed in https://github.com/orgs/bitcraze/discussions/1753

^{Originally posted by zanecodes January 23, 2025}
When reading CRTP packets from the Crazyflie 2.1+ using BLE shortly after booting the drone, I experience two issues:

1. The first 7 CRTP packets contain only null bytes
2. All other CRTP packets that were too big to fit in one BLE packet are malformed

The second split packets have their first byte cut off, and an extra junk byte appended to the end. This would seem to point to an off-by-one error in the nRF firmware, but it appears correct to me.

Additionally, it looks like the packet splitting procedure is not implemented in accordance with the documentation. Namely, it only sets the start and length bits in the first packet's control byte (it does not set the pid bits), and it does not clear the start or length bits in the second packet's control byte. It seems like the previous version of the firmware set the control byte correctly though.

Here is a partial dump of the packets I receive after boot:

9F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
9F 00 00 00 00 00 00 00 00 00 00 00 00

85 00 00 00 00 00

9F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
9F 00 00 00 00 00 00 00 00 00 00 00 00

89 00 00 00 00 00 00 00 00 00

9F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
9F 00 00 00 00 00 00 00 00 00 00 00 00

8F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

9F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
9F 00 00 00 00 00 00 00 00 00 00 00 00

9F 00 34 38 30 30 33 37 20 61 6E 64 20 49 20 68 61 76 65 20 480037 and I have
9F 30 32 34 4B 42 20 6F 66 20 66 6C 00                      024KB of fl\0      # missing '1' at the beginning, extra null byte at the end

86 00 61 73 68 21 0A                                        ash!\n

9F 00 43 46 47 42 4C 4B 3A 20 76 31 2C 20 76 65 72 69 66 69 CFGBLK: v1, verifi
9F 61 74 69 6F 6E 20 5B 4F 4B 5D 0A 00                      ation [OK]\n\0     # missing 'c' at the beginning, extra null byte at the end

9C 00 44 45 43 4B 5F 43 4F 52 45 3A 20 30 20 64 65 63 6B 28 DECK_CORE: 0 deck(
9C 29 20 66 6F 75 6E 64 0A 4B                               ) found\nK         # missing 's' at the beginning, extra 'K' at the end

9F 00 49 4D 55 3A 20 42 4D 49 30 38 38 3A 20 55 73 69 6E 67 IMU: BMI088: Using
9F 49 32 43 20 69 6E 74 65 72 66 61 00                      I2C interfa\0      # missing space at the beginning, extra null byte at the end

85 00 63 65 2E 0A                                           ce.\n

If I reboot the STM only (but not the nRF) by sending the SYSOFF and SYSON bootloader commands, I get the expected packets after boot, but they are still malformed:

9F 00 53 59 53 3A 20 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D SYS: -------------
9F 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 00                      -----------\0

85 00 2D 2D 2D 0A                                           ---\n

9F 00 53 59 53 3A 20 43 72 61 7A 79 66 6C 69 65 20 32 2E 31 SYS: Crazyflie 2.1
9F 69 73 20 75 70 20 61 6E 64 20 72 00                      is up and r\0

89 00 75 6E 6E 69 6E 67 21 0A                               unning!\n

9F 00 53 59 53 3A 20 42 75 69 6C 64 20 30 3A 62 30 34 36 37 SYS: Build 0:b0467
9F 35 38 30 31 66 63 20 28 32 30 32 00                      5801fc (202\0

8F 00 34 2E 31 30 2E 32 29 20 43 4C 45 41 4E 0A             4.10.2) CLEAN\n

9F 00 53 59 53 3A 20 49 20 61 6D 20 30 78 33 32 33 30 33 38 SYS: I am 0x323038
9F 31 33 35 33 33 35 31 31 34 30 30 00                      13533511400

9F 00 34 38 30 30 33 37 20 61 6E 64 20 49 20 68 61 76 65 20 480037 and I have
9F 30 32 34 4B 42 20 6F 66 20 66 6C 00                      024KB of fl\0

86 00 61 73 68 21 0A                                        ash!\n

9F 00 43 46 47 42 4C 4B 3A 20 76 31 2C 20 76 65 72 69 66 69 CFGBLK: v1, verifi
9F 61 74 69 6F 6E 20 5B 4F 4B 5D 0A 00                      ation [OK]\n\0

9C 00 44 45 43 4B 5F 43 4F 52 45 3A 20 30 20 64 65 63 6B 28 DECK_CORE: 0 deck(
9C 29 20 66 6F 75 6E 64 0A 4B                               ) found\nK

9F 00 49 4D 55 3A 20 42 4D 49 30 38 38 3A 20 55 73 69 6E 67 IMU: BMI088: Using
9F 49 32 43 20 69 6E 74 65 72 66 61 00                      I2C interfa\0

85 00 63 65 2E 0A                                           ce.\n

Is anyone else experiencing this issue?

[ataffanel]

Thanks for the very details description! I agree that there seems to be a bug there so I created this issue in the nrf firmware repos to track it.

How did you get all these traces? Are you working on PC or from one of the mobile client? It would help me if you had a script allowing to reproduce the problem (otherwise I can make one).

[zanecodes]

No problem! I originally captured these using BLEConsole on a Microsoft Surface Pro 7 and manually cleaned up the output for legibility.

I'm currently working on a Web Bluetooth application for controlling the Crazyflie, so I put together a quick and dirty webapp that reproduces the issue and outputs the raw packets in the same format. It should work in most Chromium-based browsers on both desktop and mobile devices.

You can reproduce the first output shown above by cold booting the Crazyflie from a powered-off state, pressing the Connect button in the webapp, and selecting the Crazyflie from the device picker. You can also warm reboot the Crazyflie STM using the Reset button, to reproduce the second output.

[zanecodes]

After additional testing, I can confirm that the issue is not specific to console CRTP packets. I also see it with TOC packets, causing the TOC group and item name in the answer packet to potentially become corrupted.

[ToveRumar]

Hi @zanecodes !

Thank you for testing this out. This really helps us a lot!

We will discuss this issue during triage, to see if this is something we will prioritize fixing.
We will update this issue accordingly.