The finer points of PWM on nRF52 using two chained buffers

RE: The finer points of PWM on nRF52 using two chained buffers

Kenneth — Tue, 05 Aug 2025 08:13:14 GMT

Hi,

Not sure I understand fully, but I guess you can check out the PWM hardware chapter on what may be possible:
https://docs.nordicsemi.com/bundle/ps_nrf52833/page/pwm.html

Kenneth

RE: The finer points of PWM on nRF52 using two chained buffers

kevinjwalters — Fri, 01 Aug 2025 21:25:40 GMT

I've now got a problem where a few pulses pop out of a buffer after we would like it to have stopped. I think this is due to a late interrupt. Some of the timings I have seen show little variability and happen to match exactly the duration of both buffers. It seems like a very advanced feature but does the PWM peripheral inside the nRF52 chips have anything that can calculate an imminent second event (in this case 10us later) and then coalesce the two into one slightly later interrupt? This isn't happening all the time, perhaps 1 in 2000 uses of the PWM.

The comments in the code suggest there's no way to do a reliable STOP after the current buffer has been processed when using LOOP and SHORTS. Is that true? Something like a PWM.EVENT_STOP_AFTER_CURRENT_BUFFER = 1 type thing?

RE: The finer points of PWM on nRF52 using two chained buffers

kevinjwalters — Thu, 31 Jul 2025 15:09:49 GMT

I've got rid of one issue but another one lurks. I'm getting an EVENT_SEQEND[0] interrupt as the PWM is started back up occasionally. That's clearly bogus because there's 128 samples to process at 800kHz so first one should arrive 160us later.

I tried adding ENABLE = 0 to the stopping code and that didn't help with this spurious interrupt. I think I may have to implement a workaround in the code to ignore interrupts which happen when the code doesn't think they should.

RE: The finer points of PWM on nRF52 using two chained buffers

Vidar Berg — Tue, 29 Jul 2025 13:31:24 GMT

It sounds like you may be on the right track. Hopefully this is it. Thank you for the update.

RE: The finer points of PWM on nRF52 using two chained buffers

kevinjwalters — Tue, 29 Jul 2025 13:06:44 GMT

I've been working my way through a few things. A brief bit of testing of PWM.ENABLE = 0 after the stop code seems to do the job but the answer to this mystery may be in the SDK library code. I see the implementation of nrfx_pwm_stop() includes a very relevant comment and additional hw register setting.

    // Deactivate shortcuts before triggering the STOP task, otherwise the PWM
    // could be immediately started again if the LOOPSDONE event occurred in
    // the same peripheral clock cycle as the STOP task was triggered.
    nrfy_pwm_shorts_set(p_instance->p_reg, 0);

I had already tried setting SHORTS to 0 but I was doing it after the STOP setting. That improved things but wasn't perfect. I'll re-order them and do some more testing.

The library code also does an ENABLE = 0 if waiting for completition is requested.

RE: The finer points of PWM on nRF52 using two chained buffers

kevinjwalters — Mon, 28 Jul 2025 17:45:58 GMT

This is on PWM2, btw.

RE: The finer points of PWM on nRF52 using two chained buffers

kevinjwalters — Mon, 28 Jul 2025 17:30:39 GMT

The code definitely passes the code that checks for the stop. From some testing today I'm become more certain that PWM.STOPS = 1 is failing very occasionally, perhaps 1 in 50000.

The complete code is a bit hairy because it's part of a streaming library but here's the stop code: https://github.com/kevinjwalters/codal-nrf52/blob/6360d434874979218e49d0202d8bfd108ae47061/source/NRF52PWM.cpp#L271-L272

For the bug I'm interested in its being used to generate the WS2812B protocol for 60 RGB pixels. I think there's actually a few bugs which contribute to that which makes it more confusing.

RE: The finer points of PWM on nRF52 using two chained buffers

Vidar Berg — Mon, 28 Jul 2025 12:15:00 GMT

Hello,

The PWM can be stopped at any time, also in the middle of a sequence. From the same PWM chapter you linked to:

[quote user=""]

The code I'm looking at waits for PWM.EVENTS_STOPPED to be non zero to indicate the stop has taken effect.

[/quote]

Are you able to confirm if the program always exits this loop? What is the symptom of the problem you are seeing?

[quote user=""]Is that saying this definitely only occurs for SEQ[1].CNT = 1? I am far from certain but I think this could explain some issues I'm seeing if it could occur for sequences of length 128 or 8.[/quote]

Yes, that is correct, SEQ[1].CNT must be equal to 1 for the conditions of this errata to be met so it does not appear to be relevant to your case.

Best regards,

Vidar