fix heltec v3 screen not working when VEXT is used

[Links2004]

This fixes the fact that the OLED screen on the heltec v3 does not work all the time.

This problem is 100% reproducebal if additional hardware is using the VEXT (3.3V) as a power src, for example a GPS module.
But I can reproduce it too by simply adding a 100µF cap to VEXT.

this change gives the VEXT 3.3V LDO regulator some time to stablize power before the OLED reset and init is perfomed.
1ms worked for my setup, but setting it too 2ms to be sure.

🤝 Attestations

• I have tested that my proposed changes behave as described.
• I have tested that my proposed changes do not cause any obvious regressions on the following devices:
  • Heltec (Lora32) V3.2
  • LilyGo T-Deck
  • LilyGo T-Beam
  • RAK WisBlock 4631
  • Seeed Studio T-1000E tracker card
  • Other (please specify below)

[HarukiToreda]

I have a cardkb, BME680 and a GPS module(GT-U7 and ATGM336H) running from the Vext of the Heltec V3 and I cannot replicate this issue. I have used the v3 to build hundreds of similar nodes and this is a first I hear this issue reported. What kind of GPS module are you using that is seeing this on? How many Heltec V3 units have you seen this issue on?

20250917_102501_1.mp4

[Links2004]

I have a V3.2, I think this is the first version where they connected the OLED screen to VEXT (based on some comments I read).

my GPS module is a GY-NEO6MV2, but I can reproduce it by only connecting a 100µF capasitor too.
so I can say for sure that its not the GPS module that is at fault here.

I can create some oscilloscope shots if we really need them, but the 2ms delay will not hurt anything.

I currently have only one V3.2 the rest are V2.

[HarukiToreda]

I want to be careful that we are not introducing a fix for an issue that appears limited to one user with a single unit. At this point, we do not know how other users are using Vext, and no one else has reported this specific behavior.

Introducing a fix without confirmation could cause unintended side effects, such as delaying startup scans for devices that depend on quick detection. Before moving forward, we need to make sure that someone else can replicate the issue and confirm the proposed fix works as expected.

For reference, I’ve tested both the V3.1 and V3.2 the same way as in the video I shared and have not seen the problem once. It’s possible that this is specific to just your unit or hardware.

[Links2004]

understanabel, I can remove the changes in variants/esp32s3/heltec_v3/variant.h.
I maintain a custom local variants for my hardware any way.

But can we at least get the option of using VEXT_ENABLE_DELAY in to the code base?

[HarukiToreda]

I don’t see any harm in keeping the rest, but it’s not my decision to make. I’ll leave the decision to the main devs. All I can point out is that further testing is needed to see if anyone can replicate the issue you had that this PR fixes, which is still not replicable at the moment.