Running critical time constrained task during BLE communication

[yes]

Our products are based on nrf52832 / nrf52840 chips as application mcu which run freeRTOS.

One of high priority task implements algorithm for controlling motor (using QDEC and PWM embedded modules) and it is critical time constrained task e.g. it should be run every 3 mSec.   

My main concern is the mutual influence between BLE (SD) interrupts and this critical task timing.

Due to the fact that motor control is implemented as close loop control algorithm which need to be periodically calculated every 3 mSecs it seems (correct me if I am wrong) that using regular BLE communication channel shall not work.

A few solutions were considered and each of them raises specific questions:

1) Masking BLE interrupts at enter to critical task and unmasking when the critical task is yielded  - How would it influence on BLE communication?

2) Using Beacon for on way data transmission from server - Does it solve the issue of BLE SD interrupts?

3) Is there any other solution to this problem?

Thanks in advance

 

 

[Turbo J]

yes said:

1) Masking BLE interrupts at enter to critical task and unmasking when the critical task is yielded  - How would it influence on BLE communication?

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.

[yes]

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

[Susheel Nuguru]

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.

[yes]

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

[Susheel Nuguru]

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.