ble stack doesn't respond

[DHunt.2]

Hello!

In my app there are the master (stm32wb55) and up to three slaves (stm32wb55 too). In addition to this I need to scan the air permanently. At some point the ble stack of the central stops responding. It means that it becomes impossible to start scanning and the central stops receiving notification from slaves. This situation could be fixed by reinitialisation of the stack ( APP_BLE_Init() command) but I need to know how to prevent this. Why could this be happening?

Maybe someone had the same issue?

Best regards,

Den

[Remi QUINTIN]

I assume the central device is using a local sensor to scan the air. How do you activate this task?

Do you register and then activate this task properly?

You should not add you task in the main while loop. This is handled by the sequencer directly.

Just guessing that this task could block the while loop leading to the lost of the connections with other peripheral devices.

Do you still miss peripheral events when not scanning the air?

[DHunt.2]

Thank you for the quick response.

I register task for the scanning and activate it as soon as the previous scan was finished. This task isn't in the while loop.

What other reasons could there be?

[Remi QUINTIN]

Did you try without scanning the air?

[DHunt.2]

No, I didn't. I will try. But the strangest thing is that issue could happen in a few minutes after connections and scans and could don't happen after couple of days of continuous testing.

[Remi QUINTIN]

Quite weird!

To summarize, the central devices scans the 3 peripheral devices and then connect to them. One the 3 connections established, the device trigs the scan of the air. Is it a one shot or a regular scan (reading the air sensor on the board every minute for example).

In last resort, please use a debugger and once the issue happens, have a look at the PC and SP to check where the code is potentially stuck or in a loop , waiting for an event that never comes.

[DHunt.2]

Yes, the central connects up to 3 peripherals whose advertising packets contain the desired mask. After 3 connections the central will scan the air for all advertising packets. It is an continuous scanning. I tried to debug but sometimes this works correctly and this problem didn't happen after some days of the continuous testing.

[Remi QUINTIN]

I think I misunderstood the term "scan the air". I thought you were reading a local sensor analyzing components (gas, pollution) in the air.

So you means that in // of the 3 connections, the device keep scanning other advertising packets.

Then the parameters used for this scanning phase could have an impact on other connections. You need to let some air time for the 3 connections to happen.

How long is this scanning phase? Is the scanning window = scanning interval ?

[Remi QUINTIN]

You can also have a look at AN5289 "building a RF application" which explain the key parameters to configure parameters for multi RF activities.

[DHunt.2]

Under "scan the air" I mean looking for all adv packets of all devices. The connection is as follows: the central starts scanning. Once an advertising packets contain the desired mask was found, the central stops scanning and connects a device with this adv packet. Once the connection established, the central device starts scanning again and then everything repeats. After 3 successful connections the central starts scanning for all adv packets.

Yes, the scanning window = scanning interval. As soon as the scan finishes after 10.24 seconds, it starts again.