Workaround random hangs when first powering on GBS-C

[nyanpasu64]

Fixes #480.

• [ ] Do reliability testing

[ramapcsx2]

Recommend you do any pin init before your delay, just making sure the IO are in a controlled state. Otherwise, good idea, probably :)

[ramapcsx2]

Oh, and what really matters: This is a WiFi enabled setup. It used to be that the ESP does all the radio setup by itself on boot, which is a huge power hog. You'll want to look into delaying any WiFi / radio setup, if that's possible. Arduino might make it difficult though.

[nyanpasu64]

I won't have time to develop further because while I was debugging my main computer's sleep-wake issues, my SSD locked up on me for the second time (previously 3 months ago). I'm running a full system backup and may have to buy a new SSD.

• By running pin init first, do you mean the three pinMode calls, or something else (perhaps startWire)? My concern is the more code you run and peripherals you initiate, the more will be drawing power on startup (and perhaps causing a hang?) Unfortunately I was never able to determine precisely what causes a hang or what state the ESP ends up in, only observe the behavior that it's indistinguishable from continually kicking the watchdog (unlikely) or being held in reset (either that, or both the CPU and watchdog are dead).
• I don't know how to delay Wi-Fi setup, or if it's running during setup(), but I do know that in my previous branch (https://github.com/ramapcsx2/gbs-control/commit/de548a4b72d97090851798995dcc768e7b57ebdf) where I spent 2 seconds flashing the LED and delaying right after setup(), I didn't get any hangs in a month or more of testing (whereas it happened every few weeks previously?).
  • A few weeks ago, I moved to leaving the barrel jack plugged in and toggling the charger itself using a power strip. I suspect this will produce quite different power-on voltage sequences from plugging the barrel jack, so I'll have to go back to the old way of power-cycling if I want to test the power-on handling. I could experiment with slow and fast plugging on the master code, to see if I can reproduce a failed startup any way.

[ramapcsx2]

Pin init: Just the basic IO setup. All the active pads should start in a resting state, where they won't cause trouble or draw current.

But really, if it's for just 500ms, then this PR is fine as it is, those won't matter.

[nyanpasu64]

Sorry I haven't looked into this further, I've mostly relied on my power strip to toggle the USB charger's AC input, rather than (flaky) barrel jack plugging. This results in (sometimes) a momentary voltage spike impulse of ±2 volts, then (a second or two later as the MacBook Air USB-C charger power strip's built-in USB power supply starts) a 5-6ms voltage ramp to 5 volts:

I haven't gotten any failed startups with this code in place, when toggling the GBS-C charger (and powering on my Wii in sleep mode) through the power strip. Is this good enough to merge?

Pin init: Just the basic IO setup. All the active pads should start in a resting state, where they won't cause trouble or draw current.

But really, if it's for just 500ms, then this PR is fine as it is, those won't matter.

I could make the following reorderings (pin_clk etc. is for the OLED menu's rotary encoder?), or leave the code as is.

void setup()
{
    pinMode(pin_clk, INPUT_PULLUP);
    pinMode(pin_data, INPUT_PULLUP);
    pinMode(pin_switch, INPUT_PULLUP);

    // Wait for power to stabilize, to reduce the risk of the ESP failing to boot until
    // manually reset (https://github.com/ramapcsx2/gbs-control/issues/480).
    delay(500);

    display.init();                 //inits OLED on I2C bus
    display.flipScreenVertically(); //orientation fix for OLED

    //ISR TO PIN
    attachInterrupt(digitalPinToInterrupt(pin_clk), isrRotaryEncoder, FALLING);

Also I found out that void startWire() calls Wire.begin() (which chains to Twi::init() with a bunch of side effects including ets_timer_setfn()/ets_task() and pinMode), then does some pin initialization as well (calling pinMode with a different argument). I don't think it's safe to move the call to startWire() before the delay, because it installs some background tasks that could run. Is it safe to leave this call after delay()?

Hopefully there's not more pin init that I've missed (are both clockgen and TV5725 hooked up to I2C and Wire?)

Sidenote: would I have been better off buying a DHO800 now, if I didn't already get a scope a few months ago?