BLE start_scan does not return on 5.3.0 on nRF52840 (CPB)

[kevinjwalters]

I was puzzling over some trivial BLE code not working on REPL on 5.3.0 on an nrF52840 based CPB, e.g.:

>>> import adafruit_ble
>>> from adafruit_ble.advertising.standard import Advertisement
>>> ble = adafruit_ble.BLERadio()
>>> scan = ble.start_scan(Advertisement, timeout=5)
>>> print(scan)
<generator object 'start_scan' at 20016600>
>>> for adv in scan:
...     print(adv.complete_name)
...
...
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "adafruit_ble/__init__.py", line 235, in start_scan
KeyboardInterrupt:

The control-c was probably after 20-40 seconds.

I loaded up some known working code from https://learn.adafruit.com/circuit-playground-bluefruit-quick-draw-duo/quick-draw-duo and this also fails in the same way and same place in start_scan().

I went back to 5.2.0 and it's working now. This and the code around line 235 suggests the problem is more likely to lay here than in https://github.com/adafruit/Adafruit_CircuitPython_BLE

I'm using libraries from adafruit-circuitpython-bundle-5.x-mpy-20200501.zip

[kevinjwalters]

There's nothing in the release notes for 5.3.0 that sounds like it could break this...

[dhalbert]

This code works for me on a Feather nRF52840 with 5.3.0, and the latest adafruit_ble straight from the repo:

import adafruit_ble
from adafruit_ble.advertising.standard import ProvideServicesAdvertisement, Advertisement

ble = adafruit_ble.BLERadio()
while True:
    for adv in ble.start_scan(Advertisement, timeout=5):
        print(adv, adv.complete_name)

I see various advertisements printed.

Note that in the example above, with timeout=5, in the REPL, by the time you get to typing the for loop, the 5 seconds probably has expired.

[caternuson]

You say you've updated libraries, but could you somehow be running into this?
adafruit/Adafruit_CircuitPython_BLE#75

[kevinjwalters]

I've gone back to 5.3.0 on a CPB and it works today, very puzzling! I would normally expect "user error" here but there's not much to go wrong.

I would have upgraded the files in lib after i did the upgrade to 5.3.0 yesterday. I would then have tapped control-d / control-c to reset things. Is there anyway the previous libraries could have had a persisting, negatve effect there?

[dhalbert]

If you did a control-d, it should be fine. A power cycle will definitely reset everything, but I very rarely do that. ctrl-d is fine.

But make sure there aren't two versions of the library, one in lib/ and one in /.

If you did ctrl-d, and then had to ctrl-c a code.py, then it's possible there was some leftover BLE state. In general I test with a code.py, or remove code.py and do manual imports of test programs (so I can have multiple test programs). And as I mentioned, testing from the REPL will have issues if you set short timeouts.

[kevinjwalters]

That's an interesting point, I did copy some libraries around last night and "missed" lib and got / but I spotted that immediately and moved them.

I did a renamed of lib to lib.from.5.0.0 before that and then made a new lib directory from the Windows host. Does that hold any possibilities for confusing things?

I think I was using 5.0.0-beta.3 pre upgrade.

[kevinjwalters]

I've repeated the upgrade from 5.0.0-beta.3 to 5.3.0 and it's ok on one CPB.

I'll close this for now and add re-open if I can reproduce it.

[caternuson]

To be really sure, you can also do storage.erase_filesystem() before copying libraries back over. That way you'll know you are starting from a clean slate. Just remember that will also wipe out any programs, so back everything up before testing.

[dhalbert]

If you were copying via Windows Explorer or a CMD command or similar, it can take Windows up to 90 seconds to actually finish writing the files and their metadata. I think you know this already, but make sure you "Eject" after doing a write like that.