NRF not booting under certain (external) conditions

[matejkarasek]

Hi,
this issue may not be (entirely) on the crazyflie side, but would appreciate some help.

Background information
We use an RC transmitter with the "DIY-Multiprotocol-TX-Module" firmware, which has some basic support of the Crazyflie CRTP, allowing to fly a crazyflie/Bolt-based drone with a transmitter with proper sticks.
The Multprotocol firmware we use attempts to connect with the default settings (E7E7E7E7E7, 2Mbit, ch. 80), which works fine in most situations.

Issue
We have noticed, that when the transmitter is powered prior to the crazyflie (so it is attempting to connect to the Crazyflie while it is booting) AND at least one deck is forced in its firmware, the NRF will not boot up. The crazyflie gets stuck with the M2 blue led on and M3 quickly blinking.

Without any deck, the Crazyflie boots up normally and connects to the transmitter.
If the deck is not forced, but detected via OW, the boot process takes longer, but eventually the Crazyflie starts up correctly and connects.

If we first let the Crazyflie boot up and then power up the transmitter so it makes the CRTP connection, again no issues, even if decks are forced.

So it seems like the NRF firmware cannot handle too many things happening at once - deck initialization and CRTP connection - while it is booting.

Not sure if it is related, but this bug was also causing the NRF to get stuck at boot:
bitcraze/crazyflie2-nrf-firmware#78

Any ideas what could be happening are welcome!

PS:
The firmware on the transmitter side is here:
https://github.com/flapper-drones/DIY-Multiprotocol-TX-Module/blob/CFlie_improved/Multiprotocol/CFlie_nrf24l01.ino

[ataffanel]

Hi, this looks like a bug we had but that has been fixed already. The bug was on the nrf side that could not handle the stream of data coming at startup. So I think this is a bug on the Crazyflie side and it is interesting that it depends of the presence of a deck. What version of the firmware are you using? If not the latest, can you try with the latest version of the firmware to see if it can be reproduces with it as well?

[matejkarasek]

Thanks Arnaud!
I tested this with the NRF firmware from the latest release (2024.2).
I will try with the latest master and report back...

[matejkarasek]

So I confirm the issue still persists with the latest NRF master (tested on cf2 with a forced deck)

[ataffanel]

Then we still have a bug. I think it is more likely to be on the STM32 side so I added a ticket in the firmware repos: bitcraze/crazyflie-firmware#1405. I think it would be good to have some automated test for this so we will first work at reproducing the problem using a Crazyradio.

[matejkarasek]

Ok, thanks, will follow it there! Hope you can reproduce it