Add LDO startup delay before GC1109 chip enable

[weebl2000]

Summary

• Add 1ms delay between enabling PA_POWER (LDO) and PA_EN (CSD) during GC1109 initialization
• Ensures VBAT is stable before chip enable, per GC1109 power-on sequence requirements

Background

The Heltec V4 and Wireless Tracker V2 use a TLV75733P LDO (controlled by LORA_PA_POWER / GPIO7) to power the GC1109 FEM. The TLV757P datasheet specifies a startup time (tSTR) of ~550us.

The GC1109 datasheet requires:

"VBAT must be prior to CSD/CPS/CTX for the power on sequence"
"CSD/CPS/CTX voltage level must not exceed VBAT voltage"

Oscilloscope measurements by @ascendr showed CSD (LORA_PA_EN) going HIGH only ~12.5us after PA_POWER — well before the LDO output stabilises. @compumike identified the TLV757P startup time as the likely cause.

This only affects cold boot initialization. During normal operation the LDO stays on (it is intentionally not powered off during sleep), so setTransmitEnable() does not need a delay.

Reference: #9029 (comments by @compumike, @ascendr, @lindorffs)

Test plan

• Flash Heltec V4, verify normal RX/TX operation
• Confirm no regression in boot time (1ms delay is negligible)

[Copilot]

Pull request overview

Adds a short startup delay during GC1109 FEM initialization so the LDO rail (VBAT/Vfem) has time to stabilize before asserting GC1109 enable pins, aligning with the documented power-on sequencing requirements for Heltec V4 / Wireless Tracker V2.

Changes:

• Include ESP32 sleep API header when building GC1109 PA support on ESP32.
• Add a 1ms delay between LORA_PA_POWER (LDO enable) and LORA_PA_EN (chip enable) during SX126xInterface::init(), currently conditioned on wakeup cause.

[Copilot]

This code calls esp_sleep_get_wakeup_cause() inside a USE_GC1109_PA-only block, but the header include is guarded by USE_GC1109_PA && ARCH_ESP32. To avoid a compile break if USE_GC1109_PA is ever enabled on a non-ESP32 target, guard the esp_sleep_get_wakeup_cause() usage with ARCH_ESP32 as well (or avoid the ESP32-specific API entirely).

Suggested change

	// On deep sleep wake the LDO was held on via RTC latch, so no delay needed.
	if (esp_sleep_get_wakeup_cause() == ESP_SLEEP_WAKEUP_UNDEFINED) {
	delayMicroseconds(1000);
	}
	// On deep sleep wake the LDO was held on via RTC latch, so no delay needed.
	#if defined(ARCH_ESP32)
	if (esp_sleep_get_wakeup_cause() == ESP_SLEEP_WAKEUP_UNDEFINED) {
	delayMicroseconds(1000);
	}
	#else
	// On non-ESP32 architectures we cannot query wakeup cause; apply conservative delay.
	delayMicroseconds(1000);
	#endif

[Copilot]

The delay is skipped for any deep-sleep wakeup cause, but on ESP32 a deep-sleep wake is a full reset and GPIO output state is typically not held unless explicitly latched (I don’t see LORA_PA_POWER being held in sleep code). That means the LDO will still be enabled immediately before this block, and PA_EN may again be asserted before VBAT is stable. Consider always waiting 1ms here (or only skipping if you can positively confirm the LDO rail is already up), rather than keying off ESP_SLEEP_WAKEUP_UNDEFINED.

Suggested change

	// TLV75733P LDO has ~550us startup time (datasheet tSTR). On cold boot, wait
	// for VBAT to stabilise before driving CSD/CPS, per GC1109 requirement:
	// "VBAT must be prior to CSD/CPS/CTX for the power on sequence"
	// On deep sleep wake the LDO was held on via RTC latch, so no delay needed.
	if (esp_sleep_get_wakeup_cause() == ESP_SLEEP_WAKEUP_UNDEFINED) {
	delayMicroseconds(1000);
	}
	// TLV75733P LDO has ~550us startup time (datasheet tSTR). Wait for VBAT to
	// stabilise before driving CSD/CPS, per GC1109 requirement:
	// "VBAT must be prior to CSD/CPS/CTX for the power on sequence"
	delayMicroseconds(1000);

[weebl2000]

See #9572, I might just combine these two changes.

[weebl2000]

Folded into #9572 — the LDO startup delay is now part of the RTC hold PR since they both address GC1109 power sequencing.