Fix infinite recursion issue in SERCOM::startTransmissionWIRE #535
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
added 2 commits
June 24, 2020 10:21
* If a significant hardware issue is struck startTransmissionWIRE calls itself to restart sending the address+r/w byte. The stack can be blown very quickly in the event of a prolonged hardware issue that warrants transmission restarts. A restart limit has been added (currently set at 5) to fix this issue. * This fixes issue #476 and it builds on work by @jrowberg in which a timeout was added addressing issue #439. * Some code simplification and tidying has followed from #439 and #476 being resolved.
* TwoWire::endTransmission layout changed to be more inline with TwoWire::requestFrom because they are essentially functioning in a similar way. * Sending of stop condition moved to within block of successful start. Apon successful start but unsuccessful read/write, stop condition is also sent - regardless of whether stop has been requested at that time.
|
|
* The aynchronous nature of the DRE and TXC interrupt flags causes issues (lockups) when the TX DATA register is empty on start and a flush is issued. Simply looking at the DRE prior to waiting for TXC is insufficient because the data register may well be empty but the shift register could still contain data, in this case SERCOM::flushUART() would return before TXC has been raised thus before flushing is complete. * bool added to SERCOM.h to indicate when it is ok for SERCOM::flushUART() to wait for the TXC flag. This flag is set when any data is written to the data register via SERCOM::writeDataUART(). It is cleared when a flush is done.
ghost
mentioned this pull request
…535 * Although the previous solution works, it doesn't respect the timeout limit imposed by @jrowberg setTimeout, and the restart limit was somewhat arbitrary. This solution does respect this hard limit and removes the self recursive nature (that tends to blow the stack) of the restarts implemented in the original source. * Tested using Arduino Zero as Master and 128x64 OLED, BM280 and ATTiny85 as slaves. SCL -> VCC, SCL -> GND, SDA -> VCC, SDA -> GND all recoverable. Multi-master tested in a similar way using 2x Arduino Zero's and 128x64 OLED, same results. * Relates to issues #476, #439 and PR #535.
ghost
closed this by deleting the head repository
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
If a significant hardware issue is struck startTransmissionWIRE
calls itself to restart sending the address+r/w byte. The stack
can be blown very quickly in the event of a prolonged hardware
issue that warrants transmission restarts. A restart limit has
been added (currently set at 5) to fix this issue.
This fixes issue SERCOM::startTransmissionWIRE() freezes on hardware issue. #476 and it builds on work by @jrowberg in which
a timeout was added addressing issue Implement SERCOM/Wire I2C timeout detection #439.
Some code simplification and tidying has followed from Implement SERCOM/Wire I2C timeout detection #439 and SERCOM::startTransmissionWIRE() freezes on hardware issue. #476
being resolved.