ESP32 Forum

I'm using a Wrover-module on a custom PCB and made a mistake by not being able to guarantee that the strapping pin MTDI is alwa
ys pulled low during power-up in order to operate the (wrover-)internal flash with 3.3V instead of 1.8V, as the latter results
in failing write ops (reads are fine, at least the previously flash firmware boots up).

I solved the issue by burning the efuse to override evaluation of MTDI, but the first ~100 are already shipped out without the
efuse being burned.

From looking at the IDF SDK it looks like I can also config VDD_SDIO in software. I found the struct `rtc_vddsdio_config_t` and respective functions like `rtc_vddsdio_set_config()` setting registers which look promising.

Since I can't actually measure VDD_SDIO as flash and esp32 are inside the wrover module I just want to have confirmation: Can I actually configure VDD_SDIO that way and does it override whatever the MTDI pin reads?

If so, I'm a bit confused about the struct's members. The header file states:

```
/**
* Structure describing vddsdio configuration
*/
typedef struct {
uint32_t force : 1; //!< If 1, use configuration from RTC registers; if 0, use EFUSE/bootstrapping pins.
uint32_t enable : 1; //!< Enable VDDSDIO regulator
uint32_t tieh : 1; //!< Select VDDSDIO voltage. One of RTC_VDDSDIO_TIEH_1_8V, RTC_VDDSDIO_TIEH_3_3V
uint32_t drefh : 2; //!< Tuning parameter for VDDSDIO regulator
uint32_t drefm : 2; //!< Tuning parameter for VDDSDIO regulator
uint32_t drefl : 2; //!< Tuning parameter for VDDSDIO regulator
} rtc_vddsdio_config_t;
```

Most likely `force` and `enable` should be set to 1, same for `tieh` as `RTC_VDDSDIO_TIEH_3_3V` is defined as `1` - but what is it with the other struct members?

What are they for exactly? What do they need to be set to in order to achieve my goal of driving the flash with 3.3V?

Yes, you can. Note that (iirc) GPIO16 and GPIO17 are also in the VDD_SIO domain, so if you have access to them, you can turn them into a GPIO and output a high level. Depending on your VDD_SIO setting, you should read either1.8 or 3.3V there.

An alternative approach would be to send the devices a firmware update that burns the VDD_SIO eFuse to the correct level. That would be generally safer, as the ESP32 won't boot up with the 'wrong' level.

Thank you! I'm still unsure about the meanings and values for `drefh`, `drefm` and `drefl`, though.

I think those are tweaking parameters for the LDO itself; probably better to leave those as is.

The problem with "leaving it so as it is" is, that the struct's default vals are already not the defaults the ESP32 starts with.
As you can see from quoted headers, `force` and `enable` are set to `1` which is clearly not how the ESP32 behaves (as it reads MTDO by default).
Hence, I'm concerned about those other 3 members being set to `2` which is the case if not setting explicitly.