NRF not responding to scans

[krichardsson]

It seems as the NRF can end up in a state where it is no longer responding to scans. I do not have a fool proof way to reach this state, but it happens from time to time when running the system tests.

Other random information:

1. It seems as the NRF is still alive since the power button works
2. The STM seems to be OK, it is possible to connect via USB
3. It is not possible to connect to the device via radio
4. The device does not respond to bootloader commands via radio

[benkuper]

Just got that with latest commit as of today, the drone will not power up from button as well

[ataffanel]

@benkuper This looks like a badly flashed firmware. This bug is describing a state where the nRF continues to work correctly when it comes to power management but stops answering the radio. It has been seen when using system-off and system-on bootloader commands multiple times on the same board.

[krichardsson]

This problem seems to be related to BLE. When the firmware is compiled with BLE=0 it does not happen.

[krichardsson]

The handling of BLE and Crazyradio are currently time slotted in the NRF. This seems to cause problems in some cases, and to fix it we have decided to disable BLE as soon as we receive a Crazyradio packet. This means that BLE will not be able until the Crzyflie has been restarted.

The time slotted implementation could lead to lost packets if a Crazyradio packet arrives while the BLE functionality is active and vise versa. This should be handled and not cause too much of a problem, but we see that sometimes it causes the NRF to behave weirdly. We are not sure what the root cause of the problem is (might be in the BLE stack for instance) and we might be hiding the issue by disabling BLE. Still we think it is the best solution and is should make the Crazyradio more reliable.