Ft2232d fixes #259
Open
Ft2232d fixes #259
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
Issuing it on a FT2232D chip causes everything to go wrong afterwards, as two unexpected 0xFF responses are returned on the next SPI transaction (e.g. when reading the Flash ID).
The "dummy" functions use commands that are only available on USB-HS chips. They do nothing on an FT2232D, resulting in no dummy bits sent at all.
This uses the undocumented Opcode 0 / Payload 9, returning 4 bytes of an ID code (somehow). Returned bytes are all 0xFF if the SRAM/Flash jumpers on the board are misconfigured, so this can be used as an indication to the user. (Observed by Logic Analyzer trace on Radiant programmer.)
|
The SRAM signature read should probably be in a function and not just pasted in there. |
Suggested by: smunaut
Good idea, did it that way. |
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.
When debugging a custom iCE40UP5K board that uses an FT2232D chip to configure the flash/FPGA, I noticed a few things in iceprog that don't work with the "D" variant.
First ist, the "divide clock by 5" command is (obviously) only available on the HS-USB chips. Issuing it on an FT2232D causes the entire sequence to go wrong. E.g. reading the flash signature bytes returns two additional 0xFF bytes before the actual signature then. Since the command is only meant to make the USB-HS chips (FT2232H etc.) compatible with the FT2232D, the solution is to simply omit it for the latter.
Further, the commands 0x8E/0x8F used in the mpsse_send_dummy_{bits,bytes} functions are also only available on the USB-HS chips. These commands are used to send the 49 dummy bits required by the iCE40 documentation once CDONE has been asserted at the end of configuration. However, since only "at least 49 bits" are required, a generic way to issue them is to just send full 7 dummy bytes instead. This can be done using mpsse_send_spi which is also available on the FT2232D.
While analyzing all this, I found the Radiant programmer issues a command during startup that retrieves a kind of signature ID from the FPGA. If this command yields 0xFFFFFFFF, this is a strong indication the board has not been correctly jumpered for SRAM operation, so I added it to iceprog, too.