-
Notifications
You must be signed in to change notification settings - Fork 7k
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
uart deadlock while using automatic light sleep (IDFGH-11870) #12957
Comments
Taking into account Sleep Modes: UART Output Handling and available UART wakeup sources (TX detection), probably better solution might be wrapping that |
@tshcherban You are right! We are aware of this issue, the MR to add the PM lock to UART driver is under internal review. |
@songruo can i help in any way with it? (some testing etc) |
@songruo |
@songruo Are you still working on this issue? Or someone else will help to fix it? |
@songruo When will this get fixed? |
Answers checklist.
IDF version.
v5.3-dev-1353-gb3f7e2c8a4
v5.2-beta1-263-ge49823f10c
v4.4.6-374-gbb8dd9d35b
Espressif SoC revision.
ESP32-S3 (QFN56) (rev v0.1)
ESP32-D0WD-V3 (rev v3.1)
ESP32-C3 (QFN32) (rev v0.3)
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
ESP32-S3/C3 DevKits
Wemos D1-Mini ESP32
ESP32/S3 custom boards
Power Supply used.
External 3.3V, USB (irrelevant)
What is the expected behavior?
Uart is working with automatic light sleep enabled
What is the actual behavior?
Uart locks indefinitely with automatic light sleep enabled
Steps to reproduce.
app main:
sdkconfig
Debug Logs.
More Information.
A problem seems to be in the
uart.c
line 1202:cyclic
xSemaphoreTake(p_uart_obj[uart_num]->tx_fifo_sem
, with indefinite timeout. It obtains the lock, and on the next iteration tries to obtain it again and eventually hangs forever.I've moved that
xSemaphoreTake
beforewhile
- and it started working as expected (on all three CPUs). However im not sure if this would be correct, because if we should wait for some ISR to happen - maybe lightsleep prevents this interrupt from trigger?The text was updated successfully, but these errors were encountered: