Fix avr_write_byte() #1897
Merged
Fix avr_write_byte() #1897
Conversation
This file contains 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
|
Seems to work well for the ATtiny15! Are there other parts/programmers I should test with to verify that this PR doesn't break anything else? USBasp: USBtiny: |
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.
This PR should fix the problems with writing to fuse and lock of the
t15(and possibly other parts). The issue is that ISP programming via direct ISP commandspgm->cmd()does not necessarily read back from the fuse/lock what was written in case there are unused bits in the memory. These unused bits are set/read using the defaults of the read/write 4 byte commands and not via factory defaults.The solution proposed here is to compare (read & bitmask) with (written & bitmask) as opposed to read with written.
While reviewing the function
avr_write_byte_default(), which I think was responsible for the false alarm "cannot write" errors, I also found that fuse and lock writes would do polling with (unset default 0xff) readback values, which is wrong, and now no longer the case.@MCUdude Please try that out.