@User do you need to configure any IOs to the management area? or just the user area? by default, the IO should be configured to the user area except for the first 5 IO.

@User: To clarify/extend what Jeff just said: (1) All I/O can operate as input to both management and user areas when the I/O is set to be an input type, so the power-up state of I/O 1 to 4 is okay for your project even though it's configured as a management input. (2) All other I/O will be set by default as user bidirectional, so if your project always sets the OEB lines high (output disabled) for GPIO that are supposed to be inputs, then the configuration should be correct for your user project on startup without applying a configuration from software.

Just posted the clarification regarding the OEB lines in the document on the repo.

OK - not sure I totally follow. But hopefully can clarify our use-case: • We do not need the management area to do anything except configure IOs. • We do not need to route any data to the management area, either from our user-area, or from the IOs. I read this thread as saying (more or less) the same as the message here: https://github.com/efabless/caravel_board/blob/main/docs/chipignite_1_silicon_notes.md#gpio-configuration - i.e. that IOs 5-37 should wake up in the “user bidirectional” state, which in all cases works for us. We’ll give it a spin with no IO-configuration-writes in the management-firmware. I’m not as clear on whether we should expect this to work for IOs 0-4.

@User: I/O 0 should be the same as the others. Only 1 through 4 are different. I only saw from one of your posts that you were using 3 and 4 as inputs, which works fine---if set to management input, you'll still see the input at the user input pin. You only need to make sure that the FTDI is not attempting to drive those pins. Which I think is the case, although I also prepared a script that puts the FTDI into bit-bang mode and sets all the pins to inputs so it won't be trying to drive anything. If you think that the FTDI chip might be interfering with your signals on those lines, you might want to try that (although I think that the FTDI stops driving those lines when you disconnect from the driver, but I'm not certain). The main question for me is what are you doing with GPIO lines 1 and 2 (if anything)?

@User - sorry I had missed this question. Our prior attempts to configure IOs 1-4 used this code here: https://github.com/ucberkeley-ee290c/caravel_board/blob/266ba2de2af047f76587fee93884d000a78f25c4/firmware/osci/slippage.py#L23

gpio_0 = GPIO_MODE_USER_STD_OUTPUT          
gpio_1 = GPIO_MODE_USER_STD_OUTPUT          
gpio_2 = GPIO_MODE_USER_STD_INPUT_NOPULL    
gpio_3 = GPIO_MODE_USER_STD_INPUT_NOPULL    
gpio_4 = GPIO_MODE_USER_STD_INPUT_NOPULL

Where, thanks to this exchange, the

USER

fields are now replaced with

MGMT

. IOs 1 and 2 appear to be working for us, as output and input respectively. But it still looks like IOs 3 and 4 are being driven. Perhaps this is the FTDI chip as you mentioned. Would you mind sharing the script that high-Z’s its pins?

@User: The script is in the caravel_board repository on the efabless github site, but it's short, so here it is. I am not certain that it actually does what it's supposed to. I'm working purely from pyftdi documentation here.