-
Notifications
You must be signed in to change notification settings - Fork 7.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apparent race condition in ledc (IDFGH-5565) #7288
Comments
Due to GitHub upload size limitations, project without binaries: Application binary: |
@acf-bwl Thanks for reporting and sorry for the slow turnaround. We had a fix under internal reviewing. The issue will be closed automatically once the fix is available on GitHub. Thanks. |
Thanks for looking into this. Our ets_delay_us workaround is working fine for now, but glad to hear the fix will be in master soon. |
I'm still seeing this issue.... any word on a fix please? |
I also see this bug in v4.2 |
Avoid adding one extra fade cycle when performing a one-time duty update. Add some notes to ledc_get_duty and ledc_update_duty APIs, so that users are aware of when the new duty will be effective. Closes espressif#7288
Avoid adding one extra fade cycle when performing a one-time duty update. Add some notes to ledc_get_duty and ledc_update_duty APIs, so that users are aware of when the new duty will be effective. Closes espressif#7288
Avoid adding one extra fade cycle when performing a one-time duty update. Add some notes to ledc_get_duty and ledc_update_duty APIs, so that users are aware of when the new duty will be effective. Closes espressif#7288
Environment
git describe --tags
to find it): v4.3 and v4.4-dev-2184-g166c30e7b2 (master at the time of this submission)xtensa-esp32-elf-gcc --version
to find it):when building on v4.3: xtensa-esp32-elf-gcc (crosstool-NG esp-2020r3) 8.4.0
when building on v4.4-dev-2184-g166c30e7b2: xtensa-esp32-elf-gcc (crosstool-NG esp-2021r1) 8.4.0
Problem Description
In certain specific cases, the esp-idf ledc driver fails to apply values set with ledc_set_duty and ledc_update_duty. In these cases, the PWM duty cycles set are neither visible on an oscilloscope, nor correctly reported by a call to ledc_get_duty. Inserting a small ets_delay_us resolves the problem. The example code provided below should reproduce this problem on esp-idf v4.3 and v4.4-dev-2184-g166c30e7b2 (master at the time of this submission). Please use the provided sdkconfig, or ensure the optimization level is set to -O2 when attempting to reproduce.
GitHub does not allow attaching of .elf files or files with no extension (ie, sdkconfig), so I have uploaded a zip of the entire project directory. It is contains the build directory with the elf, and is otherwise ready for "idf.py build" and "idf.py flash" with the current esp-idf master (v4.4-dev-2184-g166c30e7b2).
Expected Behavior
A PWM signal corresponding to the set value appears on pin 26 regardless of the ets_delay_us(). All four calls to ledc_get_duty() return six.
Actual Behavior
No PWM signal appears on pin 26 unless the ets_delay_us() line is uncommented. The first of two pairs of calls to ledc_get_duty returns zero for both channels. The second pair returns six for channel 0 and zero for channel 1.
Steps to reproduce
Build the attached code and upload it onto the board (or, upload the attached elf)
Check pin 26 of the ESP32-WROOM32 on an oscilloscope
Observe that no PWM signal (edges) is present
Observe the following lines in the console output:
Code to reproduce this issue
Please use attached zip so that you are using the same sdkconfig file. In particular, optimizations must be enabled at level -O2.
Debug Logs
Note the last two lines: the first indicates that the duty cycle of both channels is '0'. The second, printed after a 100us delay, indicates that the duty cycle of the first channel is '6' and that of the second channel is '0'. It is expected that all four values mentioned should be '6'.
The text was updated successfully, but these errors were encountered: