Running critical time constrained task during BLE communication

RE: Running critical time constrained task during BLE communication

Susheel Nuguru — Mon, 14 Jan 2019 09:36:25 GMT

I had to ask my Colleague to give his opinion on this one. He said

"If you just want to time beacon events in between the critical events. You could do that if you uses a custom advertiser, of course you will not be able to compy with the spec forr the random time component, but I think it should be ok apart from that. If you alse controls the other end you might want to use a custom protocol"

RE: Running critical time constrained task during BLE communication

yes — Thu, 10 Jan 2019 11:53:43 GMT

Regarding Beacon:

BLE communication is controlled by the client and it is a-synchronized to server tasks i.e. a-synchronized high priority interrupts when server receives client periodically communication which follow by connection interval.

When Beacon is used it can be synchronized to idle time between critical tasks and its schedule is controlled totally by the server.

It is one directional communication i.e. the server buffers data and broadcasts it as part of low task during critical task idle time.

The idle time of critical task is known or atleast can be calculated per cycle and only if it long enough Beacon message can be sent by the server.

Obviously Beacon data isn't secured and open for all observers in range. If encryption is needed it should be part of the application (not required for our specific case)

RE: Running critical time constrained task during BLE communication

Susheel Nuguru — Thu, 10 Jan 2019 11:30:08 GMT

[quote user="yes"]-> time constrained tasks can't be run as part of the application or their timing should be flexible enough for timing deviation caused by SD.[/quote]

This is absolutely correct.

[quote user="yes"]2) Does using Beacon which its transmission time can be controlled by application is practical for workaround this issue? [/quote]

Can you please tell me more on why you think the softdevice activity will be different in the case of a Beacon? I think beacon is just a special type of advertisement and the underlying softdevice activity is similar to advertising role of the device.

[quote user="yes"]3) Any other suggestion for solving this issue?[/quote]

You can disable the softdevice (get disconnected) and have your motor task running and buffering the results that needs to be transmitted to the peer. Else you can use a long connection interval, in which case you will have a lot of slots between each connection interval for the motor controlling task to run and once every connection interval, the motor task will be masked by the SD. If your application can survive this, then it is currently a simple work around to just increase the connection interval to say 200ms and you will have your motor task running for 200/3 = 66 times before it is blocked once (maybe twice).

If the above scenario does not fit your needs, then you need to have a dual core system where the BLE stack is running on one and the application has a dedicated CPU to run its time critical tasks.

RE: Running critical time constrained task during BLE communication

yes — Wed, 09 Jan 2019 11:46:13 GMT

If I may summarize above discussion:

SD has priority 0 which can't be changed (it is not exposed to application developer) and its interrupts should not be masked

According to link connection interval (aka timing deviation) can be (1M bits PHY) between ~ 0.5 - 2.5 mSec ( for empty packet and 247 Bytes data packet, respectively).

-> time constrained tasks can't be run as part of the application or their timing should be flexible enough for timing deviation caused by SD.

1) Do I miss something?

2) Does using Beacon which its transmission time can be controlled by application is practical for workaround this issue?

3) Any other suggestion for solving this issue?

RE: Running critical time constrained task during BLE communication

Susheel Nuguru — Wed, 09 Jan 2019 10:59:10 GMT

SD should have highest priority for its link layer activities. Most of the other tasks can be done at a lower priority. But Priority 0 is reserved for softdevice, so application cannot use it. This makes the design for both softdevice and application simple.

RE: Running critical time constrained task during BLE communication

yes — Tue, 08 Jan 2019 21:05:35 GMT

According to your clarification above, SD task should have the highest priority of all tasks in the system, otherwise higher priority task might cause BLE communication error

RE: Running critical time constrained task during BLE communication

Susheel Nuguru — Tue, 08 Jan 2019 19:27:35 GMT

It is not about correcting the missing ticks, its about missed housekeeping it needs to do in its many layers (Link Layer/Host/Gatt) at the exact time + it most likely need to reply to the peer at the exact time. Missing few micro seconds might already get it out of the spec and impossible to get qualified. Hence, as a rule of thumb you never should mask SD interrupts as you do not know as an application what type of house keeping SD is doing to maintain the connection or any other role.

RE: Running critical time constrained task during BLE communication

yes — Tue, 08 Jan 2019 18:59:14 GMT

Doesn't SD know to recovery from lost of one cycle?

RE: Running critical time constrained task during BLE communication

Turbo J — Tue, 08 Jan 2019 17:25:02 GMT

[quote userid="71582" url="~/f/nordic-q-a/42239/running-critical-time-constrained-task-during-ble-communication"]1) Masking BLE interrupts at enter to critical task and unmasking when the critical task is yielded - How would it influence on BLE communication?[/quote]

BLE communication won't work. The softdevice requires tight timings, and checks whether those are met in code.

You will get errors when sd detects timing violations, which are usually followed by a device reset. Check softdevice specifications for a more detailed description.