As already said in the previous Logs, the DEV_OE switch forces all the FPGA I/O pins into a HiZ state. When the DEV_OE switch is in the HiZ position, the DEV_OE led is on.

This switch comes handy in various way. A possible application is the case in which you want only use the STM32 "side" of "The Thing", and use the TEST1-2 connectors as GPIOs pins of the MCU as a "Maple Mini" clone. In this way you can simply "freeze" the FPGA holding the configuration inside.

But there is a situation in which this switch comes very very handy. Imagine that you are testing a custom interface loaded into the FPGA, and simulating this interface in a "real" situation using the STM32 as "stimulus" generator. Imagine that you have some output pins (signals from the FPGAto the STM32) and some input pins (signals from the STM32 to the FPGA).

Now what it can happen if you want change, for any reason, an input as output and an output as input in the same change?

Well, if you update the FPGA configuration at first, the new configuration will change an input as output, so this can generate a short circuit between the FPGA and the STM32 because there would be two output connected together.

So you can decide to upload the new sketch at first with the new "scenario", but in this new sketch a STM32 pin will be changed as an output, so you have two output connected together too!

The only way to break this "deadlock" is to use the DEV_OE switch to force all the FPGA I/O pins to an HiZ state and then upload the new FPGA configuration and the new sketch for the STM32 with the input/output accordingly updated. Only when both FPGA and the STM32 are updated you can safely revert the FPGA from HiZ with the  DEV_OE switch again.

Remember that the DEV_OE needs to be explicitly configured in Quartus II IDE (the DEV_OE LED will turn on also if not configured!), as explained in the Log: How to configure Quartus II. Step by step guide,