BLE blocking both cores

[spanky]

I’m trying to understand how the BLE stack impacts timings on lower priority tasks. Here’s my scenario:

I’m trying to achieve a sample rate of 100Hz on a sensor task. The BLE stack appears to be delaying that timer, even though they are pinned to different cores.

If I disable BLE advertising, that timer fires pretty close to 10ms (nanosecond variations)
With BLE advertising on, the timer fires +/-1.5ms, which is a significant variation.

• I set the BLE stack to core0
• Pinned the SD logging task to core0
• Pinned the sensor task to core1
• The sensor task uses a periodic timer set to 10ms
• I’ve implemented appropriate scheduling:
  • The 100Hz timer ISR gives a semaphore to the sensor task loop.
  • To simplify things, I disabled the actual sensor code, so all the task does is read esp_timer_get_time() and check the difference from the last time.
  • The sensor task pushes to the back of the queue
  • The logger task drains the queue to a SD card.
    • That’s how I generated the plots, but for sanity, I also did a simple “last timestamp” test and disabled the SD logging task (writing to the SD card is not the source of this delay).

I’ve tried playing with task priorities:

• The example BLE project puts the BLE 2 under the max.
  • If my timer/sensor task is above that (either by lowering the BLE priority, or raising my task priority), I don’t get advertisements on the other end.
• I've tried changing the FreeRTOS tick rate. See this post: viewtopic.php?f=13&t=1341&p=64625#p64594
• I've tried adjusting adv_int_min and adv_int_max, which partially fixes the timing on the other core, but then I lose advertisements on the other end.

The Y axis is the time difference in nanoseconds from the previous timer trigger (as read from esp_timer_get_time()). The X axis is each sample.

Here's the timing with BLE advertisements on. The timer gets delayed, and then fires early next time. That appears to explain the symmetric pattern (I just cant explain that delay beyond "something in the BLE stack"):

100hz.png (37.19 KiB) Viewed 3540 times

And if I simply turn off BLE advertisements, I get this (which is what I want):

100hz-no-ble.png (17.77 KiB) Viewed 3540 times

My question is: can I achieve a 10ms timer/sample rate on core1 with BLE on core0 (or BLE on in general)?

[spanky]

Relevant, but inconclusive post:
viewtopic.php?f=22&t=10658&hilit=ble+blocking+cores

It makes reference to:
>>>there will always be instances that need interruption of both cores. (Most extreme example would be writing to flash, which can hold up both cores for a fair amount of mS)

If it is the radio blocking both cores (which that other post indicates maybe the culprit), is there anything I can do to minimize the blocking?

My target is a 10ms interval. A variability of less than 0.5ms would be acceptable, but I'm seeing 1.5ms (on top of that 10ms interval), which throws my sampling completely out of whack.

[spanky]

Just bumping this thread to see if anyone has some insight....