ESP32 Forum

Hi,

I have designed a PCB with ESP32-WROOM-32D module and ESP-PSRAM64H PSRAM following the schematic of the ESP32-WROVER module. I observed some failures on certain devices in the field where a certain partition on the flash which I was occasionally writing to gets corrupted. This prompted me to have a second look at the design and that is when I observed that in the first iteration of the PCB, I had not connected the pull-up resistor (to 3.3V) on the GPIO16 line. In the ESP32-WROVER module's schematic, the GPIO16 pin is pulled up to the 1.8V voltage domain as per the PSRAM's requirement. Prima facie, this does not seem to have anything to do with the flash corruption. To dig further, I connected the PCB to the oscilloscope to probe the CS pin. I noticed that the CS pin of the PSRAM is pulled up by default and is pulled down as and when a transaction is initiated. Is the pin operated in a push-pull mode by the chip inside or does it have a weak internal pull-up enabled by default? Do I need this resistor anyway?

Thank you.

The state of GPIO16 after reset is oe=0,ie=1, so the value of this pin will be defined by the outside, please add an external resistor at this pin.
As for your problem, could you send me log? And please make sure GPIO12/MTDI will not be pulled high at boot-up.

Since the menuconfig contains a section to define the CS and CLK pins used for the PSRAM, I was assuming that the pin configuration is taken care of at the time of compilation. If that is not the case, can I activate the internal pull-up instead of an external pull-up resistor?

Regarding the flash corruption issue, I don't have a log since we are not able to replicate it. I think what's happening is that there are certain sections of the code where a section of the flash is erased before writing to it. There are certain tasks that trigger a restart when WiFi/MQTT disconnection occurs. When the restart is triggered immediately after the flash is erased and before the flash is written again, the system ends up with an erased partition. When the system restarts, it is unable to read the parameters it expects in the erased partition and goes into an undefined state. We have done some workarounds for this and hope that the issue will be fixed.

Since the menuconfig contains a section to define the CS and CLK pins used for the PSRAM, I was assuming that the pin configuration is taken care of at the time of compilation. If that is not the case, can I activate the internal pull-up instead of an external pull-up resistor?

------- The internal pullup will be activated after everything starts successfully, if flash could not starts correctly, there will be no pullup effect, so we suggest an external one.

I have an LED connected to GPIO12 as follows:

3.3V-----I>I-----/\/\/------GPIO12
Vf of the LED is 2.1 and the resistor is 1k ohm.

Could this be a reason for flash corruption? Considering a weak internal pull-down resistor (assuming 50k ohm) on the pin, the voltage could be in the undefined zone of CMOS operation.

It is clear to check the boot mode message if GPIO12 is pulled high during power-up.
https://github.com/espressif/esptool/wi ... de-message

It is clear to check the boot mode message if GPIO12 is pulled high during power-up.
https://github.com/espressif/esptool/wi ... de-message

The issue does not happen on power-up and the device performs as expected. So, the boot messages provided in the link you shared are useful only if being logged continuously via UART, but in our case, that is not an option since the failures have only been recorded in the field. The devices have been in the field for a while before flash corruption occurs. There are a few situations where the device restarts itself (intentional) when certain conditions are met. I am suspecting it is at this point that the system gets corrupted.