RMT: Tentative timing fix/workaround #4637
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is currently broken due to undocumented timing/ordering constraints of the peripheral, which leads to erroneous behavior when the sclk divider is large (i.e. presuamably when the RMT sclk is slow compared to some bus clock?).
Setting a large RMT SCLK divider breaks the driver in unexpected ways. There's nothing in the documentation hinting at relevant timing constraints (the only thing mentioned are limits on pulse code periods, but that's not the issue here), and the IDF code also doesn't seem to do anything special. It does order some register operations differently, first sets register and only then fills the hardware buffer, and also does more stuff (book keeping, locking, ...). This PR does the following: - match update() calls better to what IDF does (only before tx start, after tx stop, after rx start) - add some delays between configuring channels and actually starting transactions: It appears that adding a delay of about 1 SCLK period fixes all the weirdness. This suggests that some settings take a while to be properly propagated in the peripheral, and failing to provide that time results in weird glitches and hangs. It might be that IDF accidentally sidesteps this due to ordering things as follows (and due to overall doing more including locking, runtime checks, ...): 1. write RMT config registers 2. write data to RMT RAM 3. start tx whereas we switch steps 1 + 2. Thus, switching order might be a way to decrease the required delay, but that would require more research into whether that is really sufficient (e.g. when the data is short and writing it to RAM completes quickly). If there's no overall better way to fix this, maybe one could use cycle counters to just wait the minimal necessary time? In any case, this commit seems to be a minimally-invasive workaround/fix.
Give a more precise error when specifying timings that would make some of the pulses longer than the idle_threshold
MabezDev
added
the
trusted-author
[HIL trust list]Trusted users for this PR (click to expand) |
|
Author @wisp3rwind was trusted for this PR via the |
Contributor
Author
|
/hil full |
|
Triggered full HIL run for #4637. Run: https://github.com/esp-rs/esp-hal/actions/runs/20063369980 Status update: ❌ HIL (full) run failed (conclusion: failure). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Thank you for your contribution!
We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:
Submission Checklist 📝
cargo xtask fmt-packagescommand to ensure that all changed code is formatted correctly.CHANGELOG.mdin the proper section.Extra:
Pull Request Details 📖
Tentative fix for the timing/clock divider issues pointed out in the comments at #3930 (comment). See the commit messages for much more detail.
@ Espressif people: Is there any way for you to figure out what's required to make this work reliably? Whatever the precise issue with large SCLK dividers is, it seems to be entirely undocumented.
cc @kleinesfilmroellchen
Testing
HIL tests on C3.