Disabling HOLD on PSRAM CS (GPIO16) at early boot stage, because disabling it later causes crash (IDFGH-10770)

[0x0fe]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

V4.4.4

Operating System used.

Windows

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

PowerShell

Development Kit.

ESP32D0WDR2

Power Supply used.

USB

What is the expected behavior?

The expected behaviour is wake up from deep sleep without PSRAM init error.

What is the actual behavior?

PSRAM init error, preventing normal operation

Steps to reproduce.

Set a HOLD on GPIO16 (internal PSRAM CS)
1 Enter deep sleep
2 Leave deep sleep with an EXT line (tact switch),
3 Disable gpio HOLD immediately at start of firmware
4 PSRAM ID read error

Debug Logs.

ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT)
configsip: 153911750, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:3940
load:0x40078000,len:14908
load:0x40080400,len:3708
entry 0x40080608
E (476) psram: PSRAM ID read error: 0xffffffff
E (476) cpu_start: Failed to init external RAM, needed for external .bss segment

abort() was called at PC 0x40084218 on core 0


Backtrace: 0x40084b6e:0x3ffe3bb0 0x40093909:0x3ffe3bd0 0x4009903a:0x3ffe3bf0 0x40084218:0x3ffe3c60 0x40079352:0x3ffe3c90 |<-CORRUPTED

  #0  0x40084b6e:0x3ffe3bb0 in panic_abort at C:\Users\xxxxx\.platformio\packages\framework-espidf\components\esp_system/panic.c:408
  #1  0x40093909:0x3ffe3bd0 in esp_system_abort at C:\Users\xxxx\.platformio\packages\framework-espidf\components\esp_system/esp_system.c:137
  #2  0x4009903a:0x3ffe3bf0 in abort at C:\Users\xxxx\.platformio\packages\framework-espidf\components\newlib/abort.c:46
  #3  0x40084218:0x3ffe3c60 in call_start_cpu0 at C:\Users\xxxx\.platformio\packages\framework-espidf\components\esp_system\port/cpu_start.c:393 (discriminator 3)
  #4  0x40079352:0x3ffe3c90 in ?? ??:0

More Information.

I tried to disable the HOLD in the wake stub, but i cannot get it to work, i found the direct register call, but this doesnt take the GPIO as argument and it seems to use some contextual structure instead, so i am not sure how i could use this in the stub. I tried to call the IDF function directly, which doesnt work.

void RTC_IRAM_ATTR esp_wake_deep_sleep(void)  {

  //https://gist.github.com/igrr/54f7fbe0513ac14e1aea3fd7fbecfeab
  esp_default_wake_deep_sleep();
  //REG_WRITE(TIMG_WDTFEED_REG(0), 1);
  adc1_channel_t channel=(adc1_channel_t)0;
  SENS.sar_read_ctrl.sar1_dig_force = 0; // switch SARADC into RTC channel 
  SENS.sar_meas_wait2.force_xpd_sar = SENS_FORCE_XPD_SAR_PU; // adc_power_on
  RTCIO.hall_sens.xpd_hall = false; //disable other peripherals
  SENS.sar_meas_wait2.force_xpd_amp = SENS_FORCE_XPD_AMP_PD; // channel is set in the convert function
  
  // disable FSM, it's only used by the LNA.
  SENS.sar_meas_ctrl.amp_rst_fb_fsm = 0; 
  SENS.sar_meas_ctrl.amp_short_ref_fsm = 0;
  SENS.sar_meas_ctrl.amp_short_ref_gnd_fsm = 0;
  SENS.sar_meas_wait1.sar_amp_wait1 = 1;
  SENS.sar_meas_wait1.sar_amp_wait2 = 1;
  SENS.sar_meas_wait2.sar_amp_wait3 = 1; 

  //set controller
  SENS.sar_read_ctrl.sar1_dig_force = false;      //RTC controller controls the ADC, not digital controller
  SENS.sar_meas_start1.meas1_start_force = true;  //RTC controller controls the ADC, not ulp coprocessor
  SENS.sar_meas_start1.sar1_en_pad_force = true;  //RTC controller controls the data port, not ulp coprocessor
  SENS.sar_touch_ctrl1.xpd_hall_force = true;     //RTC controller controls the hall sensor power,not ulp coprocessor
  SENS.sar_touch_ctrl1.hall_phase_force = true;   //RTC controller controls the hall sensor phase,not ulp coprocessor
  
  //start conversion
  SENS.sar_meas_start1.sar1_en_pad = (1 << channel); //only one channel is selected.
  while (SENS.sar_slave_addr1.meas_status != 0);
  SENS.sar_meas_start1.meas1_start_sar = 0;
  SENS.sar_meas_start1.meas1_start_sar = 1;
  while (SENS.sar_meas_start1.meas1_done_sar == 0);
  adcValue = SENS.sar_meas_start1.meas1_data_sar; // set adc value!
  while (SENS.sar_meas_start1.meas1_done_sar == 0);
  adcValue = SENS.sar_meas_start1.meas1_data_sar; // set adc value!
  while (SENS.sar_meas_start1.meas1_done_sar == 0);
  adcValue = SENS.sar_meas_start1.meas1_data_sar; // set adc value!
  //EFUSE_RD_ADC_VREF
  SENS.sar_meas_wait2.force_xpd_sar = SENS_FORCE_XPD_SAR_PD; // adc power off
  if(adcValue<raw_wake_ref-150 || adcValue>raw_wake_ref+150){
    REG_WRITE(RTC_ENTRY_ADDR_REG, (uint32_t)&esp_wake_deep_sleep);
    CLEAR_PERI_REG_MASK(RTC_CNTL_STATE0_REG, RTC_CNTL_SLEEP_EN);
    SET_PERI_REG_MASK(RTC_CNTL_STATE0_REG, RTC_CNTL_SLEEP_EN);
    while(true){;}    
  }
  //CLEAR_PERI_REG_MASK(RTC_CNTL_DIG_ISO_REG, RTC_CNTL_DG_PAD_AUTOHOLD_EN_M); //unsure how to use this
  gpio_hold_dis(PSRAM_CS);
  gpio_deep_sleep_hold_dis();
}

[songruo]

Hi @0x0fe, may I ask a first question that why do you want to hold the PSRAM CS line before entering deep sleep? For what purpose?

[0x0fe]

@songruo because it draws some current.

[esp-wzh]

Hi, @0x0fe PSRAM power supply (VDD_SDIO pin) is turned off during deep sleep, even if the CS pin is floating, can you be sure that the current leakage is caused by PSRAM

[0x0fe]

@esp-wzh on ESP32D0WDR2 we are required to add an external 10K pullup on GPIO16 for the PSRAM CS, as far as i can remember this is what caused the leakage and the reason why i hold this GPIO high during deep sleep. I will test this again later today to be sure, but yes, as far as i can remember this was causing a current leakage (to GND).

[esp-wzh]

Hi, @0x0fe, thanks a lot for pointing this out!

Due to the shared power supply pin of PSRAM and Flash, and the low impedance characteristics between PSRAM CS# and VDD, there is the following leakage path.

After batch verification, we recommend changing the pull-up resistor of PSRAM CS pin from 10KΩ to 1MΩ, and this will also be updated to ESP32 Hardware Design Guidelines soon.

[0x0fe]

@esp-wzh
Thank you for the update on this ticket, indeed there was a current leakage. In my last hardware revision i ended up with the following arrangement :

[IO16]- [10K]-[IO0]-[<1N5819]-[IO2]

This strange arrangement has been reached over revisions to satisfy both bootstraps and ultra low power requirements with SDIO interface used and SD card VCC controlled.
When in deep sleep, with the correct GPIO configuration, i was able to reach decent current consumption, but maybe i will adjust this circuit to use a more convenitional arrangement with 1M pullup resistor in a future revision.
I will now close this ticket.