Hello All, I am working on testing my chip and I think I am missing something. I have a mixed-signal design that does not utilize the soc in the caravel. I configured the default power-up state of the gpio’s with the

user_defines.v

file to be the state that I want the gpio in. Powering up the board, there seems to be a test program already booted onto the soc that sets all the gpio to outputs and flashes them on and off (I think it might be this one: https://github.com/efabless/caravel_board/blob/main/firmware/chipignite/gpio_test/gpio_test.c). This is my surmise of what is happening because all of the digital pins are blinking and I know my ADC can’t do that ;) Does this seem reasonable? Assuming this is what is happening: is there a way to reset the gpio to their default power up states without having to boot firmware onto the soc? I’ve tried using the reset button in a variety of press/power up/power down configurations to no avail. Thanks a lot!

@Mitch Bailey may know.

🤣 Sorry to disappoint. I think @Tim Edwards is whom we need to ask.

What's the issue with just flashing a new program onto the SoC?

I was hoping to avoid needing to do that, but is that the solution?

You could maybe short across the reset button, but generally speaking, yes, the solution is just to reprogram the flash.

Ah, ok. I think I missunderstood what setting the power up state in the user_defines.v file did.

Well, the power-up state is the power-up state, but if the flash gets programmed with something that immediately overwrites the default state with something else, then the default state lasts for only a few milliseconds. So yes, erase the flash, and optionally write a program which doesn't even have to set the GPIO, if you had the default power-up state the way you wanted it. It just has to not go reconfigure the GPIO. It can be just an empty

main()

routine.

@Tim Edwards can you confirm that the evaluation board tagged as "Caravel REV5A" overwrites the default state set in the user_defines.v with a program that sets all as outputs that toggle up and down? this could explain all our current pain

I can't confirm what's on the board because I don't know how the flash is (or isn't) programmed prior to shipping. We might need to specifically institute a policy of erasing the flash before shipping to customers with analog projects.

@Tim Edwards ok, thanks do you know maybe who can give us this information?

I think Jeff DiCorpo was running a basic test on each board before shipping.

The boards are preprogrammed with a blink test (blink.hex). Erasing or overwriting the flash will address the issue above.

@Micah Tseng we confirm that our inputs were set as output and we have the "blinking" signals, as in your case

@Tim Edwards Thank you! That worked! I am now seeing stuff that seems more like an ADC

And we connected the ~RST pin from the evaluation board to ground and this avoids the setting from the user_defines.v file to be overwritten