Print full chip report when log level is sufficient

[me-no-dev]

When the user selects log level INFO or above, full chip data will be printed. Example data below:

Info printed before setup() is called

=========== Before Setup Start ===========
Chip Info:
------------------------------------------
  Model             : ESP32-S3
  Package           : 0
  Revision          : 0
  Cores             : 2
  Frequency         : 240 MHz
  Embedded Flash    : No
  Embedded PSRAM    : No
  2.4GHz WiFi       : Yes
  Classic BT        : No
  BT Low Energy     : Yes
  IEEE 802.15.4     : No
------------------------------------------
INTERNAL Memory Info:
------------------------------------------
  Total Size        :   397676 B ( 388.4 KB)
  Free Bytes        :   365332 B ( 356.8 KB)
  Allocated Bytes   :    27328 B (  26.7 KB)
  Minimum Free Bytes:   360352 B ( 351.9 KB)
  Largest Free Block:   294900 B ( 288.0 KB)
------------------------------------------
SPIRAM Memory Info:
------------------------------------------
  Total Size        :  2097152 B (2048.0 KB)
  Free Bytes        :  2095104 B (2046.0 KB)
  Allocated Bytes   :        0 B (   0.0 KB)
  Minimum Free Bytes:  2095104 B (2046.0 KB)
  Largest Free Block:  2064372 B (2016.0 KB)
  Bus Mode          : QSPI
------------------------------------------
Flash Info:
------------------------------------------
  Chip Size         :  8388608 B (8 MB)
  Block Size        :    65536 B (  64.0 KB)
  Sector Size       :     4096 B (   4.0 KB)
  Page Size         :      256 B (   0.2 KB)
  Bus Speed         : 80 MHz
  Bus Mode          : QIO
------------------------------------------
Partitions Info:
------------------------------------------
                nvs : addr: 0x00009000, size:    20.0 KB, type: DATA, subtype: NVS
            otadata : addr: 0x0000E000, size:     8.0 KB, type: DATA, subtype: OTA
               app0 : addr: 0x00010000, size:  1280.0 KB, type:  APP, subtype: OTA_0
               app1 : addr: 0x00150000, size:  1280.0 KB, type:  APP, subtype: OTA_1
             spiffs : addr: 0x00290000, size:  1408.0 KB, type: DATA, subtype: SPIFFS
           coredump : addr: 0x003F0000, size:    64.0 KB, type: DATA, subtype: COREDUMP
------------------------------------------
Software Info:
------------------------------------------
  Compile Date/Time : Jun  2 2023 00:15:19
  Compile Host OS   : macosx
  ESP-IDF Version   : v5.1-dev-4734-g8a08cfe7d1
  Arduino Version   : 3.0.0
------------------------------------------
Board Info:
------------------------------------------
  Arduino Board     : ESP32S3_DEV
  Arduino Variant   : esp32s3
  Arduino FQBN      : espressif:esp32:esp32s3:JTAGAdapter=default,PSRAM=enabled,FlashMode=qio,FlashSize=4M,LoopCore=1,EventsCore=1,USBMode=hwcdc,CDCOnBoot=default,MSCOnBoot=default,DFUOnBoot=default,UploadMode=default,PartitionScheme=default,CPUFreq=240,UploadSpeed=921600,DebugLevel=verbose,EraseFlash=none
============ Before Setup End ============

Info printed after setup() is called

=========== After Setup Start ============
INTERNAL Memory Info:
------------------------------------------
  Total Size        :   397676 B ( 388.4 KB)
  Free Bytes        :   362340 B ( 353.8 KB)
  Allocated Bytes   :    29840 B (  29.1 KB)
  Minimum Free Bytes:   360352 B ( 351.9 KB)
  Largest Free Block:   294900 B ( 288.0 KB)
------------------------------------------
SPIRAM Memory Info:
------------------------------------------
  Total Size        :  2097152 B (2048.0 KB)
  Free Bytes        :  2094828 B (2045.7 KB)
  Allocated Bytes   :      260 B (   0.3 KB)
  Minimum Free Bytes:  2094828 B (2045.7 KB)
  Largest Free Block:  2064372 B (2016.0 KB)
------------------------------------------
GPIO Info:
------------------------------------------
                  0 : GPIO
                  8 : I2C_MASTER
                  9 : I2C_MASTER
                 11 : SPI_MASTER
                 12 : SPI_MASTER
                 13 : SPI_MASTER
============ After Setup End =============

[pedrominatel]

I think this will help a lot! Thanks @me-no-dev

[pedrominatel]

LGTM

[TD-er]

Is there any documentation on what this pkg_ver is telling us for the S3/C3/etc?
I couldn't find anything yesterday.

[me-no-dev]

no and they all return 0 so far. It will probably make more sense in the future. Chips are too new

[TD-er]

Well the S3 already has seen quite a few iterations and versions.
So I find it very strange (frustrating) that there seems to be no way to read from some efuses whether the chip has embedded flash/PSRAM, its size and how it is wired, without actually access either flash or PSRAM and hopefully using the correct nr. of lanes.

[me-no-dev]

you must have skipped the top of the log?

[TD-er]

It does indeed show whether flash or PSRAM is embedded, but you can't simply see whether octal or quad mode is needed for PSRAM.
You can only see whether flash needs octal wiring via an efuse, not if PSRAM needs it.
Thus it seems impossible to detect which build might be needed when initially flashing the board.

I have 2 boards as an example:

• (A) LilyGo T-dongle, which has 16M quad flash, no PSRAM
• (B) S3 "Wemos dev pro" with 16M quad flash, 8MB octal PSRAM

Flashing a build for quad flash, quad PSRAM will work fine on board A, which doesn't have PSRAM , but on board B with 8M PSRAM you can't detect it. (and it isn't embedded in the chip, thus the "embedded PSRAM" efuse isn't set)

And when flashing a build with quad flash, octal PSRAM to board A which hasn't (such) PSRAM, you end up with a bootloop.

N.B. this board I have with 16M quad flash and 8M PSRAM (not embedded) does have an official Espressif module, so it would have been nice if Espressif did mark with some efuses how to recognize those features before flashing.

This makes it quite a trial-and-error run to properly detect what features are present on a board.

And you might say, well I don't need the PSRAM, so it doesn't matter, but using GPIO33-37 will still be wired to the PSRAM, thus using them for something else might have side-effects.

You can still read the efuses to try figuring out whether these specific pins are 'powered' via either the internal LDO or by the ESP's Vdd. But this is quite complex as you can also have override efuses active to ignore the bootstrap pin GPIO 45(??) which controls this internal voltage and I'm not 100% sure whether reading those states is actually reading an efuse, or the actual state of the power supply for GPIO 33-37 and thus maybe related to having PSRAM support enabled, etc.

TL;DR
I still think it could have been done a lot simpler by Espressif...

[me-no-dev]

5.1 supports flash auto-detection and that is turned on for ESP32S3. Should boot either way. The same technique is not possible for PSRAM

[TD-er]

5.1 supports flash auto-detection and that is turned on for ESP32S3. Should boot either way.

That's good to know, will at least save a lot of hassle.

I guess there is some other checking being done when accessing the PSRAM as I've also seen some logs showing a bit more info on the detected PSRAM like brand (??).
So would be really nice if there could still be some runtime check to be found for trying PSRAM SPI mode. It would already be useful if it were only for embedded PSRAM as those are more likely to already have an efuse set indicating it has PSRAM.

[TD-er]

I have some ESP32-S2 unit here, which does have 2M of embedded PSRAM and 4MB embedded flash.
However the chip features flags do not mention embedded flash nor embedded PSRAM.

ESP Chip ID:	5609182 (0x5596DE)
ESP Chip Frequency:	240 MHz
ESP Crystal Frequency:	40 MHz
ESP APB Frequency:	80 MHz
ESP Chip Model:	ESP32-S2FNR2
ESP Chip Features:	Wi-Fi bgn
ESP Chip Revision:	0.0
ESP Chip Cores:	1

The ESP Chip Features string is generated with this code:

    String features;

    if (getChipFeatures().wifi_bgn) { features += F("Wi-Fi bgn / "); }
    if (getChipFeatures().bluetooth_ble) { features += F("BLE / "); }
    if (getChipFeatures().ieee_802_15_4) { features += F("IEEE 802.15.4 / "); }
    if (getChipFeatures().embeddedFlash) { features += F("Emb. Flash / "); }
    if (getChipFeatures().embeddedPSRAM) { features += F("Emb. PSRAM"); }
    features.trim();

    if (features.endsWith(F("/"))) { features = features.substring(0, features.length() - 1); }
    addHtml(features);

struct esp32_chip_features {
  bool embeddedFlash{};
  bool wifi_bgn{};
  bool bluetooth_ble{};
  bool bluetooth_classic{};
  bool ieee_802_15_4{};
  bool embeddedPSRAM{};
};

esp32_chip_features getChipFeatures() {
  static esp32_chip_features res;
  static bool loaded = false;
  if (!loaded) {
    esp_chip_info_t chip_info;
    esp_chip_info(&chip_info);

    res.embeddedFlash = chip_info.features & CHIP_FEATURE_EMB_FLASH;
    res.wifi_bgn      = chip_info.features & CHIP_FEATURE_WIFI_BGN;
    res.bluetooth_ble = chip_info.features & CHIP_FEATURE_BLE;
    res.bluetooth_classic = chip_info.features & CHIP_FEATURE_BT;
    res.ieee_802_15_4 = chip_info.features & CHIP_FEATURE_IEEE802154;
    res.embeddedPSRAM = chip_info.features & CHIP_FEATURE_EMB_PSRAM;

    loaded = true;
  }
  return res;
}

This is one of those purple "Wemos" modules with the bare chip on the PCB. So both flash and PSRAM are for sure embedded in the chip and thus Espressif should have burnt those efuse bits, right?

In other words, those chip_info.features may not represent the correct state.

[me-no-dev]

In other words, those chip_info.features may not represent the correct state.

I can not comment on that. I'm just dumping what ESP-IDF provides.

[atanisoft]

In other words, those chip_info.features may not represent the correct state.

In most cases that I've seen where they don't match up they are using a SoC that doesn't have anything embedded and instead uses external flash / psram. I have yet to find any Espressif branded modules that exhibit different behaviors.

[mrengineer7777]

Intriguing. Looks helpful for issue reports. Would it make more sense to print at DEBUG level rather than INFO?

[me-no-dev]

Intriguing. Looks helpful for issue reports. Would it make more sense to print at DEBUG level rather than INFO?

that is one conversation to be had. Not sure what is the best option here.

[SuGlider]

Intriguing. Looks helpful for issue reports. Would it make more sense to print at DEBUG level rather than INFO?

that is one conversation to be had. Not sure what is the best option here.

I think that the PR is very complete, considering what is possible to be reported.
My suggestion goes about making it available, by default, within VERBOSE or DEBUG level only (not INFO).

---

Another suggestion would be about allowing any beginner users to activate it by just adding a REPORT_ENABLED(true) (or something similar) into the Sketch. It would force issuing the report, independently of the Core debug Level selected.
This may be useful for us, when investigating an open issue, to just ask this user to add this declaration in the sketch and then ask reporting back the Serrial output to us.

To achieve it, we could create some weak function that, by default, doesn't issue the report.
When the user includes the declaration, it changes the behaviour to always issue the report.

[SuGlider]

@me-no-dev - I have suggested a possible improvement.