Has anyone any experience with setting up these USB-Serial I/O chips using the FT_Prog utility? I have a couple of these on breakout boards, datasheet here:
https://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_UMFT201_220_230XB.pdf
The chip itself has four configurable general purpose I/O lines, CB0, CB1, CB2, CB3, with CB0 and CB1 brought out to the 10 pin connector on the breakout board.
Here's the problem. The above referenced datasheet has conflicting information. Table 4.5 on page 6 says that the factory default setting for CB0 is PWREN#, and CB1 is SLEEP#; whereas Table 10.1 on page 13 says that the factory default setting for both CB0 and CB1 are GPIO. Making things even more confusing, when I read the configuration of the breakout board using the FT_Prog utility program, it says that all of the lines are configured as TRISTATE, which disagrees with both tables. While I can certainly use FT_Prog to set the function to whatever I want, I'm concerned that it may not have correctly read the configuration from the chip, and so I may be working with corrupt data that could brick the device when I send the revised configuration back to it. Has anyone encountered this problem?
https://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_UMFT201_220_230XB.pdf
The chip itself has four configurable general purpose I/O lines, CB0, CB1, CB2, CB3, with CB0 and CB1 brought out to the 10 pin connector on the breakout board.
Here's the problem. The above referenced datasheet has conflicting information. Table 4.5 on page 6 says that the factory default setting for CB0 is PWREN#, and CB1 is SLEEP#; whereas Table 10.1 on page 13 says that the factory default setting for both CB0 and CB1 are GPIO. Making things even more confusing, when I read the configuration of the breakout board using the FT_Prog utility program, it says that all of the lines are configured as TRISTATE, which disagrees with both tables. While I can certainly use FT_Prog to set the function to whatever I want, I'm concerned that it may not have correctly read the configuration from the chip, and so I may be working with corrupt data that could brick the device when I send the revised configuration back to it. Has anyone encountered this problem?