open-source-silicon.dev

Please correct me if I'm wrong, in MPW3 also analog projects will not be able to use the low chain GPIO's as management SOC controlled pins due to the missing connections between IO[0] and IO[1}? Also this essentially means the UART on IO5 and IO6 cannot be used?

No, that's not true at all.  We just had to modify the calibration algorithm do that it didn't depend on IO[0] and IO[1] outputs.  The algorithm gets a bit more complicated because it's blind to those outputs, so it has to try all permutations of the first three channels to figure out where the dependent and independent hold violations are.  Once it's done that, the calibration can continue up the low side normally.

Also I assume that the flash.py script has been updated to bypass IO0 and IO1? and hence `gpio_test`  would result in IO0 and IO1 not blinking?

I had a another doubt whether would it be possible to implement the same for `caravel_hkflash.py` ? if yes it would be grateful if you could provide your inputs on how to do that.

<@U044FEHT468>:  The main thing that the `caravel_hkflash.py` needs to be concerned about is that it needs to get feedback from the flash chip on when writing has completed, and the flash chip JEDEC values, which it would normally get from the SPI SDO (GPIO[1]), and it should not exit when it gets nothing back from the query for vendor and project ID from caravel's housekeeping SPI.
For analog projects, the nucleo board version of the flash programming script (`nucleo/flash.py`) has a setup which assigns the flash MISO pin to SDO, so the flash programming script will see the output from the flash chip even though it can't see the output from the housekeeping SPI.
The problem with doing this outside of the nucleo board (i.e., in `caravel_hkflash.py` ) is that you can't automatically swap pins, so you'll need to cut the line between GPIO[1] and the FTDI, and instead connect that pin of the FTDI to "SO" on the bottom line of pins.  I haven't tried that and I won't recommend doing that without knowing if the FTDI will end up interfering with the flash.  Since GPIO[1] output is effectively floating, it may be sufficient just to jumper between SO and GPIO[1] for the duration of flash programming (with the caveat that I haven't tried it so I don't know if it works).

This would imply dissconecting the IO1 and FTDI pins and connecting the FTDI pin to MISO of the flash ( pin 2 of flash / pin D9 of caravel)during the flash process?

Also from the info you provided, since i know that the chip works from the configuration test on the nucleo, I just commented out the lines where it checks for the write project ID, and mfg ID in `caravel_hkflash.py`  and that seems to be a quick and successful work around to flashing the firmware:sweat_smile:

Sorry, I was writing the above paragraph while still thinking through the problem.  What I ended on is that I _think_ you should just be able to stick a jumper wire between SO on the bottom row of 6 pins on the development board to the GPIO[1] pin on the devleopment board---no cutting needed;  that is, no need to disconnect GPIO[1] from the FTDI.  Install the jumper wire for programming, and remove it when running.
I'm not sure if your last comment means that you were able to flash successfully with `caravel_hkflash.py`, but you need more than just commenting out the line which checks the manufacturer ID, because each programming block needs to query the SPI flash and wait for the "done" signal to tell it that programming has been done, as well as read back the memory to validate.  So you do need to bypass the GPIO[1] pin and go straight from the flash SO line to the FTDI.