3.1.2: Possible regression with WiFi-connection after ESP.deepSleep( , RF_DISABLED)

Start with the WiFiShutdown example and the ESP.deepSleep() wake path using RF_DISABLED, then compare the behavior between core 3.1.1 and 3.1.2 when WiFi.begin() runs. Reproduce the sketch's repeated wake cycles and verify that the pll_cal message no longer appears while WiFi still connects; RF_NO_CAL provides the working comparison.

Disclaimer: AI written report with edits after troubleshooting with AI assistance

Description

After waking from ESP.deepSleep() using RF_DISABLED and connecting to WiFi, the following debug message appears consistently on every single wake cycle: error: pll_cal exceeds 2ms!!!

Despite this message, the WiFi connection still succeeds and the sketch continues to run as expected (at least over a few minutes). The message appears immediately after the boot log, before any of my sketch's own Serial.println() output. This occurs 100% reproducibly, every single deep sleep cycle, not intermittently.

Basic Infos

• Hardware: NodeMCU (Lolin V3 clone / AZ-Delivery), ESP-12F module
• Core Version: 3.1.2 (issue present) / 3.1.1 (issue absent — confirmed fix by downgrade)
• Development Env: Arduino IDE 2.3.10
• Operating System: Linux 7.1.9-200.fc44.x86_64
• Probably unrelated issue, but for completeness sake: This particular board/batch freezes after deep sleep without an added resistor between S0 and 3V3

Settings in IDE

• Module: NodeMCU 1.0 (ESP-12E Module)
• Flash Size: 4MB (FS:2MB OTA:~1019KB )
• CPU Frequency: 80MHz
• lwIP Variant: v2 Lower Memory
• Upload Using: Serial

Troubleshooting:

• Tested with two different USB cables on different USB ports to rule out power supply issue as best as I can.
• Added WiFi.disconnect() before ESP.deepSleep().
• Tested with delay(1) and delay(1000) at the very start of setup(), before any WiFi calls.

Found fixes:
A: Downgrading the "esp8266 by ESP8266 Community" boards package from 3.1.2 to 3.1.1 resolved the issue completely on identical hardware and sketch. This makes a regression between 3.1.1 and 3.1.2 likely.

B: Changing the wake mode parameter from
ESP.deepSleep(sleepTimer * 1000000ULL, RF_DISABLED);
to
ESP.deepSleep(sleepTimer * 1000000ULL, RF_NO_CAL);
also produces a clean boot with no pll_cal error on core 3.1.2, without downgrading.

This suggests the regression might be related to how RF calibration is triggered on-demand (by WiFi.begin()) when waking with RF_DISABLED, rather than a general boot-time RF_CAL issue — since skipping calibration entirely via RF_NO_CAL avoids it too. Something appears to have changed between 3.1.1 and 3.1.2 in how/when RF calibration is invoked when the radio was left disabled on wake.

Sketch

(also tested and reproduced with WiFiShutdown example)

#include <ESP8266WiFi.h>
#include <NTPClient.h>
#include <WiFiUdp.h>

const int sleepTimer = 5;

const char *ssid  = "";
const char *password  = "";

WiFiUDP ntpUDP;
NTPClient timeClient(ntpUDP, "pool.ntp.org");

void setup() {
  delay(1);

  pinMode(2, OUTPUT);
  digitalWrite(2, LOW);

  Serial.begin(74880);
  while (!Serial);
  Serial.println("\nI'm alive!");

  WiFi.mode(WIFI_STA);
  Serial.print("\nConnecting to ");
  Serial.println(ssid);
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  timeClient.begin();
  timeClient.setTimeOffset(0);
  timeClient.update();
  String formattedTime = timeClient.getFormattedTime();
  Serial.print("\nTimestamp: ");
  Serial.println(formattedTime);

  WiFi.disconnect();
  delay(10);
  Serial.println("\nGoing back to sleep ...");
  Serial.flush();
  ESP.deepSleep(sleepTimer * 1000000ULL, RF_DISABLED);
}

void loop() {}

Serial Monitor

With core 3.1.2, RF_DISABLED (broken):
ets Jan 8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 3424, room 16
tail 0
chksum 0x2e
load 0x3fff20b8, len 40, room 8
tail 0
chksum 0x2b
csum 0x2b
v00043e20
~ld
error: pll_cal exceeds 2ms!!!
rf cal sector: 1020
freq trace enable 0
rf[112] : 0�
I'm alive!

Connecting to WLAN
...........
Timestamp: 10:46:19

Going back to sleep ...

With core 3.1.2, RF_NO_CAL (working) / with core 3.1.1, RF_DISABLED (working):
ets Jan 8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 3424, room 16
tail 0
chksum 0x2e
load 0x3fff20b8, len 40, room 8
tail 0
chksum 0x2b
csum 0x2b
v00043da0
~ld

I'm alive!

Connecting to WLAN
..........
Timestamp: 10:44:06

Going back to sleep ...