Controlling GPIO from a “counter” (ie HW timer) when Bluetooth (BLE) is enabled

[ballardr]

Hi, I’m having issues controlling GPIO from a “counter” (ie HW timer) when Bluetooth (BLE) is enabled.

My program flow is that I set up counter to interrupt after a period equivalent of 1200baud. Each time the interrupt runs, I set the bit logic on my bus. It’s basically a software UART, but I needed to implement a few extra features which Zephyr’s UART driver didn’t support (mainly sending serial breaks).

The issue is, when BLE is enabled, there is a delay before the logic switching actually occurs and then the switching occurs much faster than the baud rate so corrupts the data. See the below image. Note, the code for these captures are identical, the only difference is BLE being enabled.

I think my issue is caused by Bluetooth hogging resources (see #20392).

So do counter callbacks occur on the HW timer’s interrupt thread or does the HW timer’s interrupt actually signal via a semaphore and the callback occurs via the user or system thread?

• If it’s the later, is there any way to actually run code on the interrupt itself in a “zephyr” way (ie without actually implementing the ISRs directly)? It would seem silly if this was the case as it renders counters next to useless, you may as well just use k_sleep()
• If it’s the former, does gpio_pin_set() set gpio directly or does it ask the system thread to do this?

Any help on how I would get round this issue would also be much appreciated.

Note, I’m using Zephyr 2.7 (I can’t upgrade to Zephyr 3 or above due to #43428)

[cvinayak]

Do counter callbacks occur on the HW timer’s interrupt or do the HW timer’s interrupt actually signal via a semaphore (or queue) and the callback occurs via the user or system thread?

Counter callbacks occur in the timer's interrupt context. User applications are to use kernel features to defer the handling to a work queue or threads to achieve lower ISR latencies.

If it’s the later, is there any way to actually run code on the interrupt itself in a “zephyr” way (ie without actually implementing the ISRs directly)? It would seem silly if this was the case as it renders counters next to useless, you may as well just use k_sleep() as all timing benefits of using a HW timer are lost

The counter callbacks are ISRs, hence already providing the means to execute user code in ISRs. Kernel features can be used as necessary to defer operations.

If it’s the former, does gpio_pin_set() set gpio directly or does it ask the system thread to do this?

GPIO are directly set. These are set of CPU instructions, themselves consume CPU cycles in doing so.

Is there some other reason why GPIOs are not being set from the ISR

Various IRQs at priority levels will introduce ISR latencies. Even IRQs at same priority level have the natural order of priority level that will introduce latencies across ISRs.

The "bug" is that GPIO manipulation from a timer should occur when the timer interrupt occurs but it isn't.

This is not bug, real time system need careful profiling of interrupt duty cycle, CPU use, ISR latencies introduced by IRQ priorities
and interrupt locking etc. Bluetooth Controller uses couple of IRQs that can introduce latencies (even upto 1ms). I suggest you use hardware features like peripheral-to-peripheral interconnect or similar to achieve near real-time requirements.