Jitter in high priority thread loop with irq_lock and k_sched_lock

RE: Jitter in high priority thread loop with irq_lock and k_sched_lock

lepton-7 — Wed, 02 Jul 2025 14:10:19 GMT

Gosh that was an embarrassing oversight. Glad I took that issue as a sign to log off for the day. Appreciate all the help you both :)

RE: Jitter in high priority thread loop with irq_lock and k_sched_lock

hmolesworth — Wed, 02 Jul 2025 05:10:33 GMT

This code fails:

#define INV(_COMP) (_COMP | 1U << 16)
STATIC_ASSERT(0x8000 == 1U << 16,"0x8000 == 1U << 16 fails");
STATIC_ASSERT(INV(7) == 0x8007,"INV(7) == 0x8007 fails");

This code does not fail:

#define INV(_COMP) (_COMP | 1U << 15)
STATIC_ASSERT(0x8000 == 1U << 15,"0x8000 == 1U << 15 fails");
STATIC_ASSERT(INV(7) == 0x8007,"INV(7) == 0x8007 fails");

Moral: Be Assertive :-)

RE: Jitter in high priority thread loop with irq_lock and k_sched_lock

lepton-7 — Wed, 02 Jul 2025 04:32:59 GMT

I used your example and modified the nrfx_pwm>grouped_mode example to get somewhat of a solution working. I've uploaded it to a github repo here.

The only issue is that I'm unable to invert PWM polarity:

The CH2 and CH4 signals should have inverted polarity. This is after I tried setting the POLARITY bit (bit 15) for the COMPARE values loaded from RAM as shown here:

#define INV(_COMP) (_COMP | 1U << 16)

static void set_biphasic_sequence(nrfx_pwm_config_t *conf, nrf_pwm_values_individual_t *arr, uint16_t pw)
{
    uint16_t comp_on = conf->top_value - get_count_us(conf, pw);
    NRFX_LOG_INFO("On time COMP: %d", comp_on);
    NRFX_LOG_INFO("On time Inverted COMP: %d", INV(comp_on));
    uint16_t comp_on_dead = conf->top_value - get_count_us(conf, pw + 2 * DEAD_TIME_US);
    NRFX_LOG_INFO("On time COMP with deadband: %d", comp_on_dead);

    uint16_t max = conf->top_value;
    // arr[0] = (nrf_pwm_values_individual_t){comp_on, comp_on_dead, max, max};
    // arr[1] = (nrf_pwm_values_individual_t){max, max, comp_on, comp_on_dead};
    // arr[2] = (nrf_pwm_values_individual_t){max, max, max, max};

    arr[0] = (nrf_pwm_values_individual_t){comp_on, INV(comp_on_dead), max, INV(max)};
    arr[1] = (nrf_pwm_values_individual_t){max, INV(max), comp_on, INV(comp_on_dead)};
    arr[2] = (nrf_pwm_values_individual_t){max, INV(max), max, INV(max)};
}

Any idea what I'm doing wrong? I'm using an nrf52dk_nrf52832 board to test.

RE: Jitter in high priority thread loop with irq_lock and k_sched_lock

lepton-7 — Tue, 01 Jul 2025 13:13:16 GMT

If I understand correctly, the snippet you posted requires tying S1/S4 on one pin, and S2/S3 on another?

The GND phases I refer to above aren't dead times, those are specifically when both low side switches (S2/S4) are turned on so that the positive and negative terminals of the output are both pulled to ground. This is a necessary part of the output terminal behaviour. Do you still think this could be solved by one PWM module?

Both other modules are spoken for: one for a 4kHz buzzer and another the control signal for a boost converter.

RE: Jitter in high priority thread loop with irq_lock and k_sched_lock

hmolesworth — Tue, 01 Jul 2025 12:23:48 GMT

Much simpler solution is to simply use all 4 PWM output pins and no GPIOTE would then be required; a true hardware solution. I have some code which does just this, used as a pulse driver for a pump motor. There are two sequences in the PWM peripheral allowing toggling between sequences which allows the user to change pulse width and pulse frequency without stopping or interrupting the pulse train. Usually with a fixed Dead Band ("Interphase Grounding") only the pulse frequency is changed and the pulse widths auto-scale; in some cases the pulse frequency is kept constant and the pulse widths are changed allowing power control (think LED dimming). Both are possible with the PWM peripheral. Conceptually using 2 pins with external hardware looks like this (one table for each sequence):

//  Full or Half H-Bridge PWM - Variable pulsewidth/pulse frequency step lengths
//
//   +----------------------------------> COMP0 OUT[0] Compare 0 - PIN_PWM_S1S4
//   |         +------------------------> COMP1 OUT[1] Compare 1 - PIN_PWM_S2S3
//   |         |         +--------------> COMP2 OUT[2] Compare 2 - PIN_SUPPLY_EN (3 volt power source)
//   |         |         |               (COMP3 OUT[3] Compare 3 not used)
//   |         |         |
// +---------+---------+---------+---------+
// | Compare | Compare | Compare | Top     | Cycle N
// +---------+---------+---------+---------+
// | Compare | Compare | Compare | Top     | Cycle N+1
// +---------+---------+---------+---------+
// | Compare | Compare | Compare | Top     | Cycle N+2
// +---------+---------+---------+---------+
//                                 |
//                                 +----> COUNTERTOP Cycle Period 4 steps, 1MHz clocks. Range 3-32767
//                                       (LOOP       Repeat Count, number of periods - no repeats)

Using 4 pins requires other than Wave Mode or requires two PWM peripherals in synch. I'll dig out my code and post later today.

RE: Jitter in high priority thread loop with irq_lock and k_sched_lock

lepton-7 — Tue, 01 Jul 2025 08:04:05 GMT

hmolesworth It was about time I looked deeper than what the Zephyr APIs offer and I am thoroughly impressed by how powerful the PWM, PPI, and TIMER peripherals seem to be. I have an idea that I'd like your opinion on.

Turns out, if I slightly modify my output signal chain to positive -> GND -> negative -> GND, S2 = ~S1 and S4 = ~S3. Since the frequency and duty cycle is the same across all 4 (ignoring dead time for now) with S3 and S4 just being phase shifted by a known amount, I figured I could use my remaining PWM module to get the signals made. But if I understand correctly based on the PWM documentation and this discussion post, triggering TASKS_SEQSTART[n] will start the wave counter for every enabled channel and so I will not be able to use PPI to generate a PWM phase delay for channels within a PWM module, only from one PWM module to the other, correct?

If that is indeed the case, how about I setup S1 and S2 as 2 channels of the remaining PWM module operating with an up-and-down wave counter and have S3 and S4 as GPIOTE pins? This way I could set the S2 duty cycle to be slightly larger so I get deadtimes on either side of the S1 enable region.

EVENTS_SEQSTARTED[0] can then be used to start a TIMER that is already configured with the appropriately calculated CC[n] registers such they can trigger the 4 GPIOTE SET and CLR tasks that are required to form the negative phase and transition into the GND phase for the rest of the PWM period.

The only other issue I can think of is that EVENTS_SEQSTARTED[0] is only raised at the very start of the PWM module being started, but this can be solved by another TIMER that lasts exactly as long as the PWM period to restart the S3/S4 GPIOTE triggering TIMER.

Would this then in-fact be an exclusively hardware implementation to drive the H-bridge? Of course every time the user changes the pulse width/pulse frequency I should be able to stop the PWM and clear, reset all the timers, and reconfigure PWM and TIMER registers for the new settings.

Also, Vidar Berg thanks for linking that example, it helped me understand how I should approach writing this up.

Please let me know whether this vague plan seems feasible to either of you or if I have a critical misunderstanding of the peripherals.

RE: Jitter in high priority thread loop with irq_lock and k_sched_lock

Vidar Berg — Tue, 01 Jul 2025 05:53:05 GMT

I posted an example showing how you can use the nrfx pwm driver in the nRF Connect SDK here: RE: Softblink in NCS/Zephyr .

RE: Jitter in high priority thread loop with irq_lock and k_sched_lock

hmolesworth — Mon, 30 Jun 2025 20:09:55 GMT

Only 2 pins are required to drive the H-bridge (1 for S1,4 and 1 for S2,3) if using external logic though 4 pins are preferred for hardware simplicity, and the most important issue is usually to ensure that there is a way to control the dead band (non-overlap) as the drive voltages are not square waves as shown on (say) a logic analyser but instead exponential or linear ramps on both rising and falling edges. Overlap due to thresholds and sloping signals crossing can be catastrophic (shorted motor drivers exploding) or simply a nuisance (unwanted battery power loss). Here are some examples I provided for H-Bridge PWM with dead-bands; might be helpful:

pwm-interrupts

how-to-set-up-pwm-dead-time-at-the-end-of-period

RE: Jitter in high priority thread loop with irq_lock and k_sched_lock

lepton-7 — Mon, 30 Jun 2025 18:13:26 GMT

Hi Vidar,

Yes I am using the bluetooth stack in other parts of the code. I did not know that it used zero latency interrupts, thanks for the information!

RE: Jitter in high priority thread loop with irq_lock and k_sched_lock

lepton-7 — Mon, 30 Jun 2025 18:10:47 GMT

The driving circuit is an H-bridge (I've pasted a dummy setup I found online; my circuit does not connect to a motor). I have 4 GPIOs going to the 4 switch inputs on the H-bridge arms. These signals have line buffers to avoid overloading the GPIOs.

So when I call positive_electrodes(), S1 and S4 turn on. Similarly, when I call ground_electrodes(), S2 and S4 are turned on. I used 50us and 10ms times as examples in the code excerpt but I actually need to configure pulse widths between 50us - 500us delivered at 10Hz - 200Hz at runtime based on user input.

My initial idea when developing this system was to use PWM, but two channels are spoken for already. Plus, I needed the positive and negative pulses to be delivered successively with no overlap. As far as I know there aren't ways to implement a phase delay between two pins on the same PWM channel (at least in the NCS Zephyr APIs that I've checked).

Thanks for linking those threads, I took a look and they definitely are interesting. I haven't interacted with the PPI or EGU so I'll do some homework to see if those could imply a solution. Thanks!

RE: Jitter in high priority thread loop with irq_lock and k_sched_lock

Vidar Berg — Mon, 30 Jun 2025 10:46:08 GMT

Hello,

I would also recommend checking if it's possible to handle this in hardware without CPU involvement as hmolesworth suggested. Since you're seeing this issue with IRQ locking, I assume you're using one of our wireless protocol stacks, which use zero latency interrupts (not disabled by IRQ locks) to ensure that timing critical protocol events are processed on time. These will preempt any running application thread.

Best regards,

Vidar

RE: Jitter in high priority thread loop with irq_lock and k_sched_lock

LatoyaJGreiner — Mon, 30 Jun 2025 01:29:56 GMT

What a great explanation! I really appreciate you updating this thread

block blast

RE: Jitter in high priority thread loop with irq_lock and k_sched_lock

hmolesworth — Fri, 27 Jun 2025 23:55:17 GMT

Was there a reason to not just use hardware PWM to drive the GPIO? The pulses would then have no jitter; if code is required for each part of the pulse or some parts of the pulse the EGU could be used to generate interrupts which would handle any semaphores and the like; no need for thread interaction for the actual pulse timing.

Maybe share the driving circuit for the electrodes; a 4-output PWM can control the Pos-Float-neg-ground phases by selectively setting each of the 4 outputs to (say) H1D0, D1D0, H0D1, H1D0 but need to see how the outputs are driven to confirm. It is possible to use more than one PWM synchronously with 0nSec phase delay as well as no jitter. I provide an example here; the nRF52832 is simple but the changed PWM implementation on the nRF52833 required slightly different code: pwm-anomaly-nrf52832-vs-nrf52833 and start-pwms-synchronous