@Christian Duffee (@Christian Duffee)---The housekeeping SPI is what returns the manufacturer and product codes, and also what communicates directly with the SPI flash. It's also connected to the FTDI, so when you access the board using the python script, it's sending USB data to the FTDI, which translates it into SPI data and forwards it to the housekeeping SPI. The housekeeping SPI is on GPIO pins 1 to 4, which are shared by the management SoC and user project depending on the configuration of GPIO pins 1 to 4. So: If you run a program on the flash that configures the GPIO, as long as it keeps pins 1 to 4 configured correctly for having the management SoC use those pins for the housekeeping SPI, then you can always access the chip from a remote host and there is no need to reset or power cycle. However, if you configure them for some other function, then the housekeeping SPI becomes inaccessible and the only way to talk to it again is to do a power cycle with the reset button pressed. You can't let the board come out of reset until either you have (1) erased the original program off of the flash, or (2) put the SoC into reset from the housekeeping SPI.

@Tim Edwards Thanks for the clarification. I think my problem is that for (1) it fails a check before the erase procedure, even though it is able to communicate with the board somehow (as the LEDs are changing).

Sometimes the reset button can be a bit tricky to keep held down, though if you tried it on four different chips then it's unlikely you had that problem every single time. Are you power cycling by physically disconnecting and reconnecting the USB cable? One last-ditch thing to try is to just erase the SPI flash directly; by that I mean take the caravel daughterboard off, then wire the header pins at the bottom (S1, S0, CS, SCK) to the header pins for GPIO 1, 2, 3, and 4, respectively; then you can write directly to the SPI flash through USB via the FTDI (some code rewriting necessary, although I think Jeff DiCorpo has a script for that somewhere) and send it the erase command. But sudden failure after previous success makes me wonder if something completely different is going on like a cold solder joint or something. Unfortunately there are multiple ways to get the same error, since the error just means that no signal was read back from the housekeeping SDO pin; it could be a failure of the SDO pin, a failure of the housekeeping SPI, a failure of the entire chip, or a failure of the FTDI, the wiring between any of those components, or the power supplies to half of the board. All you really know is that everything was working up to the USB-facing side of the FTDI chip.

@Tim Edwards I did try to verify it wasn't a switch issue by shorting its leads directly, and have been physically unplugging/replugging the USB (with various wait times to make sure there wasn't some capacitive charge preventing the FTDI from powering down). I didn't see any obvious suspect solder joints but I'll check tomorrow to see if I can learn anything with a multimeter. I'll also try the SPI method you suggested. Thanks for your help.