Document that UART TX should be set up first #2914
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #2911 by changing the documentation.
The issue is caused by the loopback setup in our tests. When you connect RX, but the pin is not configured, there is a possibility that the pin has a low level for some time (which we try to counteract with a pullup resistor). This may cause the UART peripheral to register a start condition, and receive a byte - which, because we connect TX immediately, and set it to high, will be a
0xFF
. The hardware doesn't seem to notice that the start bit is too short.When we set TX first, we set a high level on the pin, and then the peripheral does not misdetect a start bit on the subsequent RX configuration.
ESP-IDF sets the pins together, TX-first, likely because of this same phenomenon.
This issue really only affects cases where the ESP32 listens to its own output, and the line is only driven by the ESP32. In other cases, the RX line's level should be determined by an external device and so we can't say what causes a low signal level - communication, break, or some other cause.
As the order of the pin setup is set by the user, the pins may be configured mid-operation and I can't really find a way to stop receiving a byte anyway, I'm not sure what else we can do other than document that the user should be careful when listening to their own output.