Kavya Sreedhar
02/28/2023, 7:43 PMmake 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).Tim Edwards
02/28/2023, 8:58 PMmake 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
.Kavya Sreedhar
02/28/2023, 11:31 PMmake 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
proppy
03/01/2023, 1:55 AMKavya Sreedhar
03/01/2023, 3:59 AMproppy
03/01/2023, 4:02 AMKavya Sreedhar
03/01/2023, 4:03 AMbrew tap riscv-software-src/riscv
brew install riscv-tools
Error: Your Command Line Tools are too outdated
on the brew install stepbrew install riscv-tools
workedproppy
03/01/2023, 4:15 AMKavya Sreedhar
03/01/2023, 4:15 AMreg_mprj_io_27 = GPIO_MODE_USER_STD_INPUT_PULLDOWN;
in gpio_test.c then I would want to make sure the 27th config is C_USER_BIDIR_WPD
in gpio_config_io.py?GPIO_MODE_USER_STD_ANALOG
in gpio_test.c correspond to in gpio_config_io.py? the possibilities I see are below, but I’m not sure which one fits
C_USER_OUT = 0
C_MGMT_IN = 1
C_USER_BIDIR = 2
C_DISABLE = 3
C_ALL_ONES = 4
C_USER_BIDIR_WPU = 5
C_USER_BIDIR_WPD = 6
C_USER_IN_NOPULL = 7
C_USER_OUT = 8
GPIO_MODE_USER_STD_OUTPUT -> C_USER_OUT
GPIO_MODE_USER_STD_INPUT_PULLDOWN -> C_USER_BIDIR_WPD
python3 ../gpio_config/gpio_config_checker.py
PASS: Low gpio matches.
FAIL: *** High gpio does not match ***
0: : ____IO[37]___ I___IO[36]___ I___IO[35]___ I___IO[34]___ I___IO[33]___ I___IO[32]___ I___IO[31]___ I___IO[30]___ I___IO[29]___ I___IO[28]___ I___IO[27]___ D___IO[26]___ I___IO[25]___ I___IO[24]___ I___IO[23]___ I___IO[22]___ D___IO[21]___ I___IO[20]___ I___IO[19]___
0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 1100000000000 0110000000001 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000
make check
Tim Edwards
03/01/2023, 3:45 PMreg_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!Kavya Sreedhar
03/01/2023, 3:52 PMGPIO_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?Tim Edwards
03/01/2023, 3:57 PM000
which turns the output buffer (and also the input buffer) off completely, regardless of the state of OEB.Kavya Sreedhar
03/01/2023, 3:59 PMTim Edwards
03/01/2023, 5:05 PMC_DISABLE
in the configuration file and GPIO_MODE_USER_STD_ANALOG
in the C file configuration.Kavya Sreedhar
03/02/2023, 12:41 AMGPIO_MODE_MGMT_STD_INPUT_NOPULL
in the C file, should we be using C_MGMT_IN
in the python file?GPIO_MODE_USER_STD_ANALOG
in the C code and C_DISABLE
in the Python code. (If I set that to an input and input_nopull that gpio is fine so it seems to be this configuration that causes problem with make check
)C_MGMT_IN
or C_MGMT_OUT
with GPIO_MODE_USER_STD_ANALOG
and then run make gpio_config_data.c
and then make check
, it passes (but C_DISABLE
fails)…it doesn’t sound like C_MGMT_IN
or C_MGMT_OUT
is the right thing to do thoughGPIO_MODE_MGMT_STD_INPUT_NOPULL
for user project I/Os…I just wanted to make sure that should say MGMT
and not USER
(GPIO_MODE_MGMT_STD_INPUT_NOPULL
vs GPIO_MODE_USER_STD_INPUT_NOPULL
)?Ayushman Tripathi
03/03/2023, 2:35 AMTim Edwards
03/03/2023, 2:58 PManalog_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.make check
result whether or not you care if it fails. For example, in analog mode you want the first three bits (the output mode) to be 000
, which turns off all digital buffers. If that's true, then the rest of the configuration bits are all don't-cares. If make check
reports that the analog channel "fails" because it was specified as "user analog" and the management mode bit got set, then that's an error that can be ignored. Likewise, if the failures occur in channels you aren't using, then you can ignore them.Ayushman Tripathi
03/06/2023, 7:14 PMTim Edwards
03/06/2023, 7:32 PM000
, 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.Praveen raj
03/11/2023, 3:24 PM