Full power PWM not applied correctly (latest development version)

[jonschz]

PROBLEM DESCRIPTION

This issue affects lights on the latest development build (this issue is not present in v12.5.0). Setting channels to 100 % (e.g. Color1 000000FFFF) results in a PWM output of roughly 50 %, while outputs lower than 100 % (e.g. FE instead of FF) are unaffected. This issue appears in the latest commit but not in v12.5.0 (see below for details).

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues
• Searched the problem in discussions
• Searched the problem in the docs
• Searched the problem in the chat
• Device used (e.g., Sonoff Basic): Wokwi Simulation for Athom LB01-15W
• Tasmota binary firmware version number used: commit 7f312ba
  • Self-compiled
• Provide the output of command: Backlog Template; Module; GPIO 255:

[inapplicable]

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

[not used]

• Provide the output of this command: Status 0:

[not relevant]

• Set weblog to 4 and then, when you experience your issue, provide the output of the Console log:

00:00:03.845 CMD: color1 000000ffff
00:00:03.859 PWM: i=0 used=1 pwm_val=000 vs 000 pwm_phase=000 vs 000
00:00:03.865 PWM: i=1 used=1 pwm_val=000 vs 000 pwm_phase=000 vs 000
00:00:03.871 PWM: i=2 used=1 pwm_val=000 vs 000 pwm_phase=000 vs 000
00:00:03.876 PWM: i=3 used=1 pwm_val=3FF vs 000 pwm_phase=000 vs 000
00:00:03.881 PWM: err1=0 err2=0
00:00:03.885 PWM: analogWritePhase i=3 val=3FF phase=000
00:00:03.891 PWM: i=4 used=1 pwm_val=3FF vs 000 pwm_phase=3FF vs 000
00:00:03.896 PWM: err1=0 err2=0
00:00:03.900 PWM: analogWritePhase i=4 val=3FF phase=3FF
00:00:03.915 RSL: RESULT = {"POWER":"ON","Dimmer":100,"Color":"000000FFFF","HSBColor":"0,0,0","White":100,"CT":327,"Channel":[0,0,0,100,100]}

TO REPRODUCE

1. Compile the most recent tasmota32-debug.
   2.1 Simulate the circuit here by following the instructions on the left
   2.2 Alternatively, upload the compiled firmware to an ESP32, hook D18 and D19 up to some measurement device (like an oscilloscope), then run

Backlog GPIO15 416; GPIO16 417; GPIO17 418; GPIO18 419; GPIO19 420
[wait for restart]
Color1 000000FFFF

EXPECTED BEHAVIOUR

D18 and D19 should be on (about) 100 % output. However, they are closer to 50 %.

SCREENSHOTS

Simulated digital analyzer output with Color1 000000FFFF:

With Color1 000000FEFE:

ADDITIONAL CONTEXT

I tracked down the most likely cause to this line:

Tasmota/lib/libesp32/ESP32-to-ESP8266-compat/src/esp8266toEsp32.cpp

Line 385 in 7f312ba

if (duty >> (pwm_bit_num-1) ) ++duty; // input is 0..1023 but PWM takes 0..1024 - so we skip at mid-range. It creates a small non-linearity

This contrasts the documentation stating

duty – Set the LEDC duty, the range of duty setting is [0, (2**duty_resolution) - 1]

The reason why this previously hidden problem came to light appears to be this (fully correct) change. In the past, the gamma correction curve would map 1023 to 1017 which was then increased to 1018 in analogWritePhase(). Now, the gamma curve (correctly) maps 1023 to 1023 which is then increased to 1024 in analogWritePhase.

In any case, commenting out the line in analogWritePhase solves the issue on my side.

Disclaimer: I do not have an ESP32 and did my testing in Wokwi, so I cannot fully guarantee that the behaviour is identical on real hardware. However, the values passed to ledc_set_duty_with_hpoint are clearly not within spec, and in the simulator there is a stark difference between v12.5.0 and the current development version.

(Please, remember to close the issue when the problem has been addressed)

[s-hadinger]

Could you please test with a version that includes #18666

There was a mixup in the gamma tables, and the change you mention earlier is no more applicable. I don't have a device at hand to test.

[jonschz]

The version I tested is the most recent development branch as of today, so it includes the pull request you mentioned.

Edit: It does look like #18666 also contributed to uncovering this issue, though.

[s-hadinger]

Ok thanks. Actually 1023 should match to 1023 in the gamma table, because it means full on. The problem is that the hardware PWM takes a value between 0 and 1024 (which counts for 1025 values). We need to apply the duty correction or the LED is not fully on when setting full range.

From the tests we did in the past, the esp-idf documentation was wrong stating that values are 0..1023, they are 0..1024. This is easy to test with a real LED. Just set the led as PWM_i, setting full range should result in the led OFF, which is not the case with 1023, and it is with 1024.

The output from logic analyzer doesn't make sense. I really advise to test with a real device.

[s-hadinger]

Just checked the code of esp-idf, duty is passed unchanged to the hardware. So I suspect that the doc si still wrong about that. If the simulator was done based on esp-idf specs and not on hardware specs, this might explain the discrepancy.

[jonschz]

Thank you for your input! I can confirm your findings and I also took a look at the ESP32 data sheet which supports your observation:

Let DUTY_RES = 10 and HPOINT = 0. Then the counter counts 0,1,...,1023,0,1,... (cf. p. 383). Now let DUTY=1023. Then the PWM output is turned on at 0, then turned off at 1023, and back on on the next 0 (cf. p. 384), so it is not turned on permanently.

I will close this issue and file bug reports with esp-idf and wokwi.

[Jason2866]

@jonschz Tried the simulator. It is not useable for running Tasmota firmware. In my tests it always bootlooped a few times before starting correctly. This is a behaviour which Tasmota detects and resets user done settings.
In its current state the simulator is not a tool which can be used with Tasmota.

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1156
load:0x40078000,len:11456
ho 0 tail 12 room 4
load:0x40080400,len:2972
entry 0x400805dc

00:00:00.001 HDW: ESP32-D0WDQ6-V3 (PSRAM)
00:00:00.047 CFG: Loaded from NVS, Count 9
00:00:00.095 QPC: Count 1
Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). Exception was unhandled.

Core  1 register dump:
PC      : 0xffffffff  PS      : 0x00060c30  A0      : 0x800eb775  A1      : 0x3ffb1ec0  
A2      : 0x3ffb1ef0  A3      : 0xffffffff  A4      : 0x3f42cf60  A5      : 0x3f4076d0  
A6      : 0x00000000  A7      : 0x00000006  A8      : 0x8010dcb0  A9      : 0x3ffb1eb0  
A10     : 0x3ffb1ec8  A11     : 0xffffffff  A12     : 0x3f42cf60  A13     : 0x3f4076d0  
A14     : 0x00000000  A15     : 0x00000006  SAR     : 0x00000014  EXCCAUSE: 0x00000000  
EXCVADDR: 0x00000000  LBEG    : 0x4008dd71  LEND    : 0x4008dd81  LCOUNT  : 0xffffffff  


Backtrace: 0x7ffffffc:0x3ffb1ec0 |<-CORRUPTED




ELF file SHA256: 0000000000000000

Rebooting...
ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1156
load:0x40078000,len:11456
ho 0 tail 12 room 4
load:0x40080400,len:2972
entry 0x400805dc

00:00:00.002 HDW: ESP32-D0WDQ6-V3 (PSRAM)
00:00:00.048 CFG: Loaded from NVS, Count 9
00:00:00.083 FRC: Some settings have been reset (2)
Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). Exception was unhandled.

Core  1 register dump:
PC      : 0xffffffff  PS      : 0x00060c30  A0      : 0x800eb775  A1      : 0x3ffb1ec0  
A2      : 0x3ffb1ef0  A3      : 0xffffffff  A4      : 0x3f42cf60  A5      : 0x3f4076d0  
A6      : 0x00000000  A7      : 0x00000006  A8      : 0x8010dcb0  A9      : 0x3ffb1eb0  
A10     : 0x3ffb1ec8  A11     : 0xffffffff  A12     : 0x3f42cf60  A13     : 0x3f4076d0  
A14     : 0x00000000  A15     : 0x00000006  SAR     : 0x00000014  EXCCAUSE: 0x00000000  
EXCVADDR: 0x00000000  LBEG    : 0x4008dd71  LEND    : 0x4008dd81  LCOUNT  : 0xffffffff  


Backtrace: 0x7ffffffc:0x3ffb1ec0 |<-CORRUPTED




ELF file SHA256: 0000000000000000

Rebooting...
ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1156
load:0x40078000,len:11456
ho 0 tail 12 room 4
load:0x40080400,len:2972
entry 0x400805dc

00:00:00.001 HDW: ESP32-D0WDQ6-V3 (PSRAM)
00:00:00.047 CFG: Loaded from NVS, Count 9
00:00:00.082 FRC: Some settings have been reset (3)
Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). Exception was unhandled.

Core  1 register dump:
PC      : 0xffffffff  PS      : 0x00060c30  A0      : 0x800eb775  A1      : 0x3ffb1ec0  
A2      : 0x3ffb1ef0  A3      : 0xffffffff  A4      : 0x3f42cf60  A5      : 0x3f4076d0  
A6      : 0x00000000  A7      : 0x00000006  A8      : 0x8010dcb0  A9      : 0x3ffb1eb0  
A10     : 0x3ffb1ec8  A11     : 0xffffffff  A12     : 0x3f42cf60  A13     : 0x3f4076d0  
A14     : 0x00000000  A15     : 0x00000006  SAR     : 0x00000014  EXCCAUSE: 0x00000000  
EXCVADDR: 0x00000000  LBEG    : 0x4008dd71  LEND    : 0x4008dd81  LCOUNT  : 0xffffffff  


Backtrace: 0x7ffffffc:0x3ffb1ec0 |<-CORRUPTED




ELF file SHA256: 0000000000000000

Rebooting...
ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1156
load:0x40078000,len:11456
ho 0 tail 12 room 4
load:0x40080400,len:2972
entry 0x400805dc

00:00:00.002 HDW: ESP32-D0WDQ6-V3 (PSRAM)
00:00:00.048 CFG: Loaded from NVS, Count 9
00:00:00.083 FRC: Some settings have been reset (4)

[jonschz]

I have encountered the same, but I have still been able to work with it reasonably well. Most of the time, the settings I made did not get erased.

My main motivation is to fix another issue related to lights without buying a development board (I don't have a serial interface to my Tasmota light, so I want to minimise the odds of uploading broken firmware). For this application, the simulator worked well enough until I encountered this issue. I agree that the simulator cannot fully replace development boards in its current state.