BLE fails to init sometimes

[incognico]

Hi all,

I am seeing some occasional issues instantiating BLE:

unknown response: 0e 04 01 4c
fail3 0e

Then setting active(1) [or 0] hangs. A CTRL-C breaks out to the REPL.

Is there some way to validate the object creation? The object is of the type <BLE> even when this happens

--Nick

[jimmo]

hi,

I am seeing some occasional issues instantiating BLE:

Could you please confirm which version of MicroPython and which PYBD model you're using. (Just copy the output from a soft reset).

Does WiFi work fine?

[incognico]

Sorry, I'm not using WiFi in the project so can't comment on that just yet.

MicroPython v1.12 on 2019-12-20; PYBD-SF6W with STM32F767IIK

In case it's relevant: I have the eMMC installed but not yet powered up during BLE object creation.

[jimmo]

MicroPython v1.12 on 2019-12-20; PYBD-SF6W with STM32F767IIK

In case it's relevant: I have the eMMC installed but not yet powered up during BLE object creation.

Thanks. I've got a WBUS-EMMC here somewhere will test it out myself and get back to you.

FWIW one of the main things that active(1) does is upload the firmware blob into the BT controller, and the "fail3" indicates that it's failing during fw upload.

[jimmo]

In case it's relevant: I have the eMMC installed but not yet powered up during BLE object creation.

OK I've done a few power cycles with the WBUS-eMMC installed and ble.active(True) works every time. Also works when the eMMC is active too.

So when you say " some occasional issues", how occasional do you mean? Any hints on how to repro?

[incognico]

I've had it starting (RTC alarm) every 20 seconds from standby(). It beacons the battery percentage (LiFePO4 fuel gauge, i2c) for 1 second then drops into standby() and the process repeats.

The 20-second period is short but I wanted to make sure this was robust and also so I could see the battery being impacted faster.

This setup has never once made it through the night (in ~2 weeks) without the above issue and unfortunately since it hangs in a [relatively] high-current state, has killed a couple of the little LiFePO4s

I have implemented a WDT workaround and it's been running (3 devices) for ~48 hours now ok.

Clearly this is an unusual scenario and I understand if it goes on the "maybe later" pile

--Nick

[jimmo]

OK thanks for the info, I'll see if I can set up something like this and leave it running overnight.

I've had it starting (RTC alarm) every 20 seconds from standby().

So just to clarify, main.py is along the lines of:

ble.active(True)
# report temperature via ble
ble.active(False)
rtc.wakeup()
pyb.standby()

i.e. it does an active(False) before the standby()?

Interestingly I had just a few days ago added "Low-power mode (e.g. beacon while main chip in standby)" to the TODO list on https://github.com/micropython/micropython/issues/5186 so investigating the interaction with the main chip going into standby was definitely an area that I wanted to look into anyway.

[incognico]

Yep, that's all correct, including the active(False).

And now you can see why I was asking about the beaconing in standby