Hi everyone, to run gpio_test, do we need to run

make flash_nucleo

and then

make sim

(https://github.com/efabless/caravel_board/blob/main/firmware_vex/gpio_test/Makefile)? The diagonstic steps are working for me (https://github.com/efabless/caravel_board/blob/main/firmware_vex/nucleo/README.md).

make check

is more meaningful than `make sim`; the former is just the final line of output for the latter and shows what configuration ended up in the registers after programming, based on the calibration results (

make sim

shows every single step of the data shifting into the registers, which is more information than you really need). Neither one depends on the program being flashed. Once you do

make flash_nucleo

, the board should get reset and you should see all the GPIOs toggling (which you can test with an oscilloscope or frequency counter---somebody should write a simple program that allows the Nucleo to read each GPIO pin and confirm whether or not it's toggling). If not all GPIOs are toggling, then the points of failure should match what's reported by

make sim

.

I was able to run

make check

which looks okay, but I get the below error with

make flash_nucleo

.

(caravel) kavya@Kavyas-MacBook-Pro gpio_test % make check
python3 ../gpio_config/gpio_config_checker.py
PASS: Low gpio matches.
PASS: High gpio matches.
(caravel) kavya@Kavyas-MacBook-Pro gpio_test % make flash_nucleo
/usr/local/bin/riscv64-unknown-elf-gcc -I/Users/kavya/Desktop/Kavya/sky130_xgcd_bringup/caravel_board/firmware_vex/gpio_test -I../ -I../generated/ -O0 -mabi=ilp32 -march=rv32i -D__vexriscv__ -Wl,-Bstatic,-T,../sections.lds,--strip-debug -ffreestanding -nostdlib -o gpio_test.elf ../crt0_vex.S ../isr.c gpio_test.c
make: /usr/local/bin/riscv64-unknown-elf-gcc: No such file or directory
make: *** [gpio_test.elf] Error 1

You have to have a risc-v toolchain installed.

awesome, thanks!

@Kavya Sreedhar can you comment on the issue on what toolchain you installed?

yes, I had to do the following on MacOS Ventura

brew tap riscv-software-src/riscv
brew install riscv-tools

Awesome! do you want to add this to the issue? That's would be a good contribution for other that are on macosx.

Sounds good!

Sorry for the late reply---time zone differences. So when you see

reg_mprj_io_27 = GPIO_MODE_USER_STD_INPUT_PULLDOWN;

in the C code: The configuration ends up being held in two places. One is in the housekeeping module, and one is near the GPIO pad. The serial loader is what gets it from the housekeeping to the pad; however, in our code, we're bypassing the serial loader and bit-banging the data into the serial chain directly. The value

reg_mprj_io_27

is the register address in housekeeping. It is important for only one reason: The housekeeping looks at bit 3 (input disable) to determine which direction the single-wire interface between housekeeping (management) and GPIO goes. If INP_DIS = 1, then the management SoC drives the wire; if INP_DIS = 0, then the GPIO drives the wire. So the value in the register doesn't matter much but you want to make sure that the management SoC and the GPIO are not both trying to drive the data wire at the same time. The simplest thing to do is to just set each GPIO channel to an input mode or output mode, depending on what the GPIO is supposed to be doing. If the GPIO is being used by the user project, then set the channel to an input. I would suggest setting

GPIO_MODE_MGMT_STD_INPUT_NOPULL

for all channels being used by the user project. The

gpio_config_def.py

file will be created once by the calibration process and should not be changed except when changing the chip under test. Our policy has been to copy the file to a name indicating which chip it is for, like

gpio_config_def_F1_7.py

, and then making

gpio_config_def.py

a symbolic link to the one corresponding to the chip currently being programmed and tested. The

gpio_config_io.py

file is what needs to be changed to match what you want the GPIOs to be doing in your C program. The builder then generates the

gpio_config_data.py

file (and the corresponding C file) which contains the bit stream definition. Don't change

gpio_config_io.py

without re-running the build process, so that

gpio_config_data.py

is always in sync with

gpio_config_io.py

. Otherwise the checker will give wrong results. I hope that answers your questions!

Thank you so much for the explanation, this greatly clarifies things! Just to double check, then

GPIO_MODE_MGMT_STD_INPUT_NOPULL

should be used for user io_in, io_out, and analog_io and we set io_oeb appropriately to choose between io_in and io_out? And if we are using analog_io[i], then it doesn’t matter what io_oeb[i] is set to?

All of that is correct, yes. For analog I/O, the output mode is set to

000

which turns the output buffer (and also the input buffer) off completely, regardless of the state of OEB.

Sounds good! How do we actually indicate that we are using an analog I/O pad then?

@Kavya Sreedhar: Any channel that you are connecting an analog signal to should be set to

C_DISABLE

in the configuration file and

GPIO_MODE_USER_STD_ANALOG

in the C file configuration.

awesome, thank you! I was missing the C_DISABLE. I will try that.

@Tim Edwards I have also tried with C_DISABLE and GPIO_MODE_USER_STD_ANALOG. For me also make check fails for High_GPIO.. Make check passes for GPIO_MODE_MGMT_STD_INPUT_NOPULL and C_MGMT_IN. My analog outputs were not coming correctly in both cases.

If you have any analog signal connected to an

analog_io

pin on a GPIO, you want to keep both the (digital) input and output buffers turned off. The output buffer is the most critical because it will interfere with your analog signal. The input buffer will draw crowbar current if your analog signal is mid-range. So both of your configurations above will work, but the first one is better. Also, if you have the Nucleo board connected, make sure that the Nucleo board pins aren't interfering with the signals.

@Tim Edwards Thanks for the reply. For GPIO_MODE_USER_ANALOG_STD_PROJECT and C_DISABLE case, using make check I found that GPIO 24, doesn't have its 3LSBs as 000. Consequently, on logic analyzer it outputs 3.3V while all other analog IO pins are at 0V. expected output from rest of the analog output pins is between 1.4V~1.8 V.

@Ayushman Tripathi: For the screenshot you show, GPIO 24 has the low bit set, which should be fine (that is, you should be able to ignore the error) because as long as the three highest bits are

000

, then the pad is disabled (both input and output digital buffers are turned off), and the state of the lowest (management enable) bit has no effect on the GPIO function at all.

@Tim Edwards @Kavya Sreedhar, Thanks for this thread, it greatly helped me to make the GPIO analog pins work!