ESP32 Forum

If it is capable to do LOG after entering such state, then it means something still working allowing that logging communication. My idea is to turn off everything (same as in deep-sleep) with an exception that ram/psram are preserver. Ok, that implies cores also must be powered ON but in such "hibernate state". All the rest: Radio, AD modules, uart modules, timer modules, GPIO (all pull-ups/ pull-downs, before that I already turned off all my rest of hardware on board, which is powered through mosfet under control of ESP), RMT, SPI, TWAI, I2S, I2C .... literaly everything.

In that word literraly there are: weak pullups related to flash and psram which are also under internal conttrol of ESP. Also pull-ups/downs in RTC domain GPIOs ...... literraly everything.
But there is no document which collects all those things at single place related to light-sleep and all things which impacts to current consumption in such a critical state on battery power.
All those (and probably a lot of other not mentioned) things make a difference, will some small battery powered IoT be cappable to "survive" in such a RAM/PSRAM retention state from which it can continue working, for 5 months or only 5 days.

I never can be 100% sure, did I turn off all of what is possible to be turned off

Light sleep should turn off almost everything, see https://docs.espressif.com/projects/esp ... s.html#id1
Also note the Power Management Locks which may prevent the chip from going to sleep when you ask it to.

The only way is to get an amp meter and measure current. But what should be expected current consumption in such a state (with 8MB PSRAM chip)?

When the chip's current draw goes down from 50-200mA to 1-2mA, you know it has entered sleep mode.
If you care about the last sub-mA power savings, you may want to consider using deep sleep. Deep sleep also preserves RTC-RAM, so you can store some application state to be resumed from there.

Deep sleep would be good option if PSRAM is not populated with 6MB already compressed important data which must be preserved (rest of 2MB in PSRAM are routines which couldnt fit in internal RAM). So deep sleep is not an option in this case. PSRAM Memory retention is required. Is it safe to disable internal pullups on flash/psram CS signal. I mean, if CPU do not address any of those in such a light sleep mode ,can there be changes on those lines making spurious writtes or corruption?

Im curious, how hard would be to implement DeepSleep with PSRAM retention. For example:

making separate PSRAM voltage line under the control of an external mosfet which would be under control of ULP which can run in deep sleep. Then by booting from deep sleep just skipping PSRAM initialization. Is it possible? Could heap be properly initialized in such a scenario? I guess some heap data would need to be preserved in lets say NVS, before entering DeepSleep to be able to recover lets say 6MB array of data in PSRAM after powering up.