changing PWM duty + sleeps sometimes leads to ignoring duty setting

[JohnMTu]

Hello,

using this code

from machine import Pin, PWM
from time import sleep

led = PWM(Pin(21)) # 21=21 pre pico W a ESP32, 4=D2 pre esp8266
led.freq(1000)

while True:
    led.duty(1023) 
    sleep(1)

    led.duty(0)
    sleep(0.0001)

it happes usually within 1 minute, that i get 0% (0V) for 1 seconds. But expected was only 0.1ms (10 000x less)

Using sleep(0.0001) instead situation is opposite .. it's most of the time 0% and sometimes 99.9% duty appears.

tested with ESP WROOM-32 and FW MicroPython v1.19.1 on 2022-06-18; ESP32 module with ESP32.

it's pretty strange behavior.
What is explation to that? Is duty(1023) call async and possibly delayed after sleep?

thanks
best regards
jan

[JohnMTu]

Here are images, how it looks like

on duty 1023 duty is only 99.90%, hence that light green color. (#9445)
For other noise: didn't have ground of probe connected.

[robert-hh]

Hard to say. I tried to replicate that. With a WROVER type board, it ran for hours without triggering. With a WROOM type board, it happened within minutes. See the screen shot below. The zoomed area is the last PWM cycle before the dropout. Nothing strange with it.
But there is a strange dependency from the second sleep. If I set it to 1 ms, there is no output at all. Setting it to 2 ms the dropouts are gone.

[robert-hh]

No further pulse loss after 1 hour of running. Looks like the problem is changing the duty rate while the previous cycle was not finished.

[JohnMTu]

tested the same with ESP8266 and raspberry Pico W and for both it seems to be fine.

[JohnMTu]

EDIT: it might be, this was wrongly tested, as REPL didn't take last 1 or 2 commands...
Doing a new version, with logic and also PWM init in function....

---

testing now with

from machine import Pin, PWM
from time import sleep

led = PWM(Pin(21)) 
led.freq(1000)


while True:
    led.duty(1023)  
    sleep(1)

    led.duty(0)
    sleep(1)

expectation is simple: for 1 second output it must be most of the time high, and for next 1 second it must be low ...

• esp32-20220618-v1.19.1.bin - it's not a case .. it's kind of random
• esp32-20220117-v1.18.bin - seems to work fine
• esp32-20210902-v1.17.bin - seems to work fine
• esp32-20210418-v1.15.bin - seems to work fine
• esp32-20190316-v1.10-227-g696549d2e.bin - seems to work fine

[JohnMTu]

tested also esp32-20220929-unstable-v1.19.1-455-ge4d90be68.bin - also bad behavior

[JohnMTu]

well, not i'm pretty confused....
it's pretty random whether it works or not for me ...
i'm just repeating this in cycle:

• reset board with button
• ctrl+E, paste, ctrl+D

starting to have a feeling sometimes perhaps last sleep(1) isn't taken.. will make method for that and call it as last step of script and retest

[robert-hh]

It seems hard to replicate. Here, everything looks fine. The pattern is at both boards always like the screen-shot below:

[JohnMTu]

now i'm 99% sure, that it was problem with REPL not taking all lines of code by pasting it ...
now using revisited code with logic in function and calling it at the end to make sure, whole code is present after pasting it to REPL.
I returned to second sleep of 0.0001 as with 1 it seems to just work.
Also tried to replace sleeps with "dummy calculation loop", seems not having impact.
Hence it's about initial problem again, tested agaist different firmwares using same board.
Results are above code.

# https://github.com/micropython/micropython/discussions/9447
#
# expectation: most of the time HIGH state. (measured on oscilloscope)
#
# ESP WROOM-32                         | useSleep=True                                                  | useSleep=False
# v1.10-227-g696549d2e on 2019-03-16;  | OK                                                             | OK
# v1.12 on 2019-12-20;                 | OK                                                             | OK
# v1.13 on 2020-09-02;                 | OK                                                             | OK
# v1.14 on 2021-02-02;                 | OK                                                             | OK
# v1.15 on 2021-04-18;                 | notOK (mostly LOW for 0.001 and mostly high for 0.0001 sleep)  | NotOK (random)
# v1.17 on 2021-09-02                  | notOK (mostly LOW for 0.001 and mostly high for 0.0001 sleep)  | NotOK (random)
# v1.19.1 on 2022-06-18;               | notOK (mostly LOW for 0.001 and mostly high for 0.0001 sleep)  | NotOK (random)

from machine import Pin, PWM
from time import sleep

useSleep = False


def action():
    print('starting')

    led = PWM(Pin(21)) # 21=21 pre pico W a ESP32, 4=D2 pre esp8266
    led.freq(1000)

    while True:
        #led.duty_u16(65535)
        led.duty(1023)
        print('high')
        if useSleep:
            sleep(1)
        else:
            i = 0
            for x in range (1, 100000):
                i = i+x
            if i // 2 != 3:
                print(i)

        #led.duty_u16(0)
        led.duty(0)
        print('low')
        if useSleep:
            sleep(0.001)
        else:
            i = 0
            for x in range (1, 100):
                i = i+x
            if i // 2 != 3:
                print(i)


action()

btw i also noted other thing: on older FWs i can paste long script to REPL without issue. With 1.19.1 i need many retries until it's correctly pasted...

[robert-hh]

With v1.19.1, try a sleep of 0.002 (longer than 1 PWM cycle).

[JohnMTu]

with 0.002 it works fine.

I tried also to skip 2nd wait completely. Situation is, that signal is mostly HIGH, but randomly LOW for 1sec duration.

Looks like asking for trouble, if i would e.g. animate PWM using timer and then comes external request to change it to something else. If duty changes are close enough from each other, maybe bad thing will happen.

i would say, both are bugs (Especially as it worked with older firmware).

more details:

from machine import Pin, PWM
from time import sleep

def action():
    print('starting')

    led = PWM(Pin(21)) # 21=21 pre pico W a ESP32, 4=D2 pre esp8266
    led.freq(1000)

    while True:
        led.duty(0)
        print('low')
        led.duty(1023)
        print('high')

        sleep(0.1)

action()

with this there is randomly LOW state for 100ms. This is unexpected behavior.

---

And maybe simulation of more real life situation (using timers ... as "demo" replacement of events based on which i want to control PWM). If they are close to each other, bad thing happen ... one-before-last duty remains "active".

from machine import Pin, PWM, Timer
from time import sleep

t1 = Timer(1)
t2 = Timer(2)

led = None


def cb(_):
    t2.deinit()
    led.duty(1023)
    print('high')
    t2.init(period=1, mode=Timer.ONE_SHOT, callback=cb2)


def cb2(_):
    led.duty(0)
    print('low', led.duty())


def action():
    global led
    print('starting')

    led = PWM(Pin(21)) # 21=21 pre pico W a ESP32, 4=D2 pre esp8266
    led.freq(1000)
    cb(None)

    t1.init(period=100, mode=Timer.ONE_SHOT, callback=cb)


action()

output:

starting
high
>>> low 1023
high
low 1023

scope view:

[JohnMTu]

same test on other board (but also ESP32 WROOM-32), fw v1.11-187-g00e7fe8ab on 2019-08-04;

console still reports bad duty after setting LOW, but on scope is fine:

starting
high
>>> low 1023
high
low 1023

(also tried with PERIODIC timer t1 and looks fine on scope

[robert-hh]

There was a major rework of ESP32 PWM last year, first merge in September 2021. So v1.18 included the changed version. But there were more smaller changes since then. And there might have been a change in the idf version being used for the builds.
Anyway, this looks like a problem of the esp-idf, which cannot be solved in the MicroPython code.

[JohnMTu]

problem exists since at least v1.15 on 2021-04-18 according to my tests

[robert-hh]

But couldn't that have been the "pasting of code" problem?

[JohnMTu]

don't think so .. i tested it many times, with same results.. And it would need to be suprisingly bad paste, as debug output was printed.

To tripple check this, i put this to file, so i could verify content and run in again and again without pasting:

from machine import Pin, PWM
from time import sleep

def action():
    print('starting')

    led = PWM(Pin(21)) # 21=21 pre pico W a ESP32, 4=D2 pre esp8266
    led.freq(1000)

    while True:
        led.duty(0)
        print('low')
        led.duty(1023)
        print('high')

        sleep(0.1)

action()

result on ESP2 with 1.19.1: randomly LOW state for 100ms. (which is wrong).
Result on ESP32 with 1.11-187-g00e7fe8ab: randomly LOW state for 1ms (Expected).

how there were 2 different boards ...
To ensure it's micropython issue, not a board, i'm reflashing one which had 1.11-187-g00e7fe8ab also to 1.19.1.
Results with same script: randomly LOW state for 100ms. (which is wrong).
So imho confirmed as micropython version related issue.

[robert-hh]

This confirms that changing the duty rate twice in a single PWM period is critical. The delay before the next setting has to be 2 periods, since that it the time required to update the duty cycle. See also the issue report at the espressif's site: espressif/esp-idf#7288. So the bug is known, and espressif claims to work on it.
I made different test with alternating frequencies, showing that the frequency switch has glitches, like too long cycles. Since this is all by call to espressif's RTOS, the best that could be done is documentation.