Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info

Considering the thread solved and closed as of . LDO replacement solves RESET on power up of WiFi radio and secondary, less frequent RESET issue solved by moving ISR to SRAM for execution.

Table of Contents
minLevel1
maxLevel7

Hardware Issues/ Enhancements

  •  
    Status
    colourRed
    titleISSUE
    Stronger power supply. 5V operation works, but 3.3V battery does not. Starting to see evidence that this may be an issue with my build. Need to keep open minded.
  • Upgrade from 200mA LDO to 500mA LDO solved my RESET issue.

    • Now using TC1262-3.3V LDO

  •  
    Status
    colourGreen
    titleENHANCEMENT
    Hall Effect sensors on measurement devices
  •  
    Status
    colourGreen
    titleENHANCEMENT
    I2C based counters for rainfall and wind anemometer revolution count
  •  
    Status
    colourGreen
    titleEnhancement
    Full low current analysis
    •  Mount ESP32 on PCB and keep only what I need in the design

Troubleshooting the RESET issue I see on my PCB

  1. When RESET or initial power on happens on non 5V USB power (using LiIon battery and MCP1700)

    1. WiFi radio begin() will fail and system reboots

    2. second connect will pass

    3. sequence fails again after deep sleep and timer WAKE

  2. TODO: Scope 3.3V supply and look for any signs of droop

    1. monitor regulator output and 3V3 pin on dev module

  3. Observed that fully charged battery will RESET controller after deep sleep, but as voltage gets < ~4.1V controller stops resetting.

4:30am - Experiment start

19:10pm

  • MQTT topic added to report boot count

  • Boot count starts to increment after deep sleep, but microcontroller randomly still RESETs

  • I now have a way to know when things are working properly

  • One can clearly see when boot count is getting RESET to 0

...

**Notice how bootCount periodically resets after incrementing for some time. This is typical behavior is the ESP32 RESETs when activating WiFi radio.

I replaced the MCP1700 with a TC1262-3.3V LDO (500mA) and the system works on a fully charged battery immediately! I’ll post results from overnight run to see if any system resets occur.

...

...

Happy to report that I ran overnight without incident!

Long term TODO:

  •  Hall Effect sensor based wind and rainfall measurement
  •  I2C based wind counter, easier to periodically read instantaneous wind values with ULP
  •  Layout ESP32 on main PCB, get rid of the dev module entirely
    •  Really attack the deep sleep current support
    •  Add FET switch for powering down all peripherals while in deep sleep
    •  No power LED constantly drawing current
    •  LoRaWAN stack
    •  

Log of efforts

Power supply reboot debug issue

Ordered 500mA LDO’s from Microchip. TC1262 (qty 10)

New LDO works great! Very haphazardly tacked on the existing PCB design, but no more brownout and RESET.

...

Battery Life Testing

Using a 3100mA LiIon cell

6am, battery testing with 15min timer settings to evaluate battery life with no recharge

4am battery voltage falls < 3.7V

Current Measurement

Mode

Current

Deep Sleep

~20ma

Wake

???

Wake with WiFi

~120ma

DEV board and deep sleep current capabilities are not compatible with each other

Thomas was able to get sleep current <1mA when removing the power LED and the USB to UART converter chip.

New PCB arrived

Thomas designed a PCB version that accepts the new LDO. I’ve been examining the new board and experimenting with it.

...

NVM rainfall backup looking more appealing every day.

...

Disappointed that I’m seeing RESETs, but found something in my code

Code Block
languagecpp
  //Average samples
  if (msTotal || samples)
  {
    windSpeed = 1.49 * 1000 / (msTotal / samples);
  }

My logic to check for divide by zero is wrong. Should be &&

Code Block
  //Average samples
  if (msTotal && samples)
  {
    windSpeed = 1.49 * 1000 / (msTotal / samples);
  }

Running boot experiment without sensor connected now. msTotal and samples will both be zero and this case will never happen.

After running 1000 boot cycles without incident, I’ve proven to myself that the secondary RESET issue was caused by software.

Now at 1800 boot count with no issues. Hardware is stable.

Image Added

Secondary, intermittent reset issue seems to be solved by properly marking ISR routines to be copied to SRAM.

IRAM_ATTR in function definition informs program to copy and execute code from SRAM.

Code Block
//=======================================================
//  windTick: ISR to capture wind speed relay closure
//=======================================================
void IRAM_ATTR windTick(void)
{
  timeSinceLastTick = millis() - lastTick;
  //software debounce attempt
  //record up to 10 ticks from anemometer
  if (timeSinceLastTick > 10 && count < 10)
  {
    lastTick = millis();
    tickTime[count] = timeSinceLastTick;
    count++;
  }
}