Photon2 BLE stalls as central device when peripheral dies

[tnilsen]

I'm using a PHOTON2 in the central role to connect to a peripheral. This works great all day long. Now I'm testing some fault scenarios. If I reset the external peripheral I can see that my onDisconnect callback is called and the Log.Info also says connection was lost.

However, peer.connected() still returns TRUE. Even if I close the connection it still returns TRUE. This now causes my loop() to stall since I'm still calling BLE functions and eventually the PHOTON2 self resets.

Note: I am doing all BLE operations in the loop(). Only flags and Log.Info calls are made in any callback.
Anyone have any insight? I'm using OS 5.6.0.

EDIT: When I reset the peripheral I get this message in Log.Info:
[wiring.ble] TRACE: Disconnected by remote device.
After this my loop stalls since peer.connected() is still true. I tried gracefully shutting down the connection after this via a flag from the onDisconnect() callback, but the peer.conencted() still returns true. I looks like an expected disconnnect messes up the BLE stack.

EDIT2: I ran it on an Argon with OS 4.0.1 and it behaved properly. I could gracefully lose connection and re-open once I powered peripheral back.

EDIT3: I ran it on a Boron with OS 4.0.2 and it behaved properly. I could gracefully lose connection and re-open once I powered peripheral back.

[tnilsen]

BLE Argon/Boron/Photon2 as Central Device - packet fragmention loss of 1 character

I'm using (right now) an Argon running OS4.2.0. I'm using it in the BLE Central Role and have connected to a peripheral. I'm polling it for data. The peripheral reports it will send 297 bytes of data via the UUID characteristic. This of course causes packet fragmentation. I then read the peripheral for data. I get 244 bytes on the first read and by review I see the data is intact. I get 52 bytes on the second read which is 1 byte short of 297. By review, it loses the first byte of the second me…

NOTE: OS versions 4.1.0/4.2.0/5.6.0 all have this fragmentation issue.

[gusgonnet]

@tnilsen

If I reset the external peripheral I can see that my onDisconnect callback is called

Hi, what if you force the disconnect yourself when this function gets called?
I mean, set a flag, and from loop() you disconnect. You'll need to refactor your code so it checks this flag instead of peer.connected()

PS: I do not know what peer.connected() would return true. Maybe there's a timeout at play here?

[tnilsen]

@gusgonnet

disconnect

Did that - no joy. Released OS Versions 4.x.x work great. 5.6.0 not so much. BTW easy to reproduce.
I'll stick to version OS 4.1.0 for now. It does have the packet fragmentation single byte loss issue as I've described, but luckily that loss does not affect me.
Thanks for your reply!

[tnilsen]

GitHub - tbnilsen/Particle-BLE-to-Shelly-Switch: Particle IoT chip in BLE...

It might help with some code. As said, works properly on 4.x versions, but drops a byte on a fragmented BLE message.

[gusgonnet]

@tnilsen

After this my loop stalls since peer.connected() is still true.

Hi Terje, how does your loop() look like?

I believe now that a "simple" line like:

BLE.peerCentral().connected()

will toast or confuse the BLE in some way, make loop() stop executing for ~9 minutes until it panic resets.

Thanks