FTDI FT230X USB-Serial CBus confusion

[BobW]

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?

 

[Pommie]

The tables don't disagree, they both state I/O with 4.5 adding how they are configured. If when you read the config it's different, could it be that someone has configured it different from the factory default and then returned it to the supplier?

Mike.

 

[BobW]

I think they do disagree. GPIO in this context is a specific type of I/O, as it is listed separately from PWREN# and SLEEP# in the same table. Hence, PWREN# is not GPIO.

I doubt that they would have been reconfigured and then returned to the supplier, though not impossible, I guess. I have two different ones that were in different factory sealed packages. Both have the same configuration or lack thereof.

Anyway, I'm more confident that the configuration that was read in from the chip is not corrupted, because I saved the config file to disk and then read it in an xml editor. The parameters all look reasonable. So, I'll probably take a chance and try reconfiguring the chip.