Open johnheenan opened 4 years ago
Further tests point to a hardware issue and provide an explanation why the deep sleep current is the same, 300 uA, when the +3V3 pin is powered directly with 3.3 volts, bypassing the ME6217 LDO voltage regulator.
In summary two issues are identified
I use the term 'signal' in the CAD sense to mean the labelled connections on the schematic, whether real signal connections or power connections or otherwise and where in practice the labels are ALSO often used as a guide to normal conditions and so are not taken literally.
When bypassed the regulator provides a low resistance path from its output to input (from +3V3 to +5V in the schematic). The Si2307 P Channel Mosfet (Q1) is on due to unpowered 5V signal at GND level, noting that the 5V and +5V are different signals. There is no VBUS or solar input to 5V. The mosfet can be consdered on (gate is at GND) so it provides a low resistance path between the source at signal +5V to the drain at VBAT. Reference provided in added comment
Hence there is a low resistance path from +3V3 back to VBAT
I placed a 750 ohm resistor across VBAT and GND. Paradoxically the voltage rose slightly from 2.9V to 3.2V. Since the voltage across the 750 ohm resistor was 3.2 volt is was passing 4.3mA and showing every indication more current could be passed.
Straight off this means that current is being lost through 200K ohm resistance to measure ADC0 (say arounf 15 uA). The TP4056 charger IC has a high level on BAT through the VBAT signal. Even the battery protecion IC, the DW01FA is affected.
However none of the above may be significant compared to what is happening with the CP2104 USB to UART bridge. Although the CP2104 is not connected to 3V3 or VBAT signals, there was a measured 3.1v on the TX and RX pins, perhaps enough for significant current leakage when not powered. The VDD and VIO pins (VCC_UART) is at 0.23V.
It would be good to determine the full set of current leaks.
Of course there are obvious solutions
Of course in ultra low power scenarios the type of additional circuitry is not included or if it is (such as in development boards for ultra low power devices) jumpers are included to cut current paths so as tests can be made.
Even with all of the above, under normal circumstances 300 uA would be considered excellent. But if we wish to deploy to an environment where we expect batteries to last for years and not to be able to charge them then we expect to be able to bypass circuitry with direct connections to power pins and not get current leakage.
With regard to the USB-UART bridge and possible current leakage, it is common to be able to snap off the USB-UART bridge part of circuitry and reconnect later though pins. Also if not needed it makes the board smaller.
With regard to mosfet being turned on and so conducting backwards, following is taken from https://electronic-products-design.com/geek-area/electronics/mosfets/using-mosfets-as-general-switches
"Usually the Source pin must be more positive than the Drain (however this isn’t true when using a P Mosfet to provide reverse polarity protection for instance).
"Whenever the Gate voltage is lower than the (Source Voltage – Gate Threshold voltage) the MOSFT conducts. If the gate voltage is higher than this it does not conduct. The greater the voltage difference from the Source the more the MOSFET can conduct."
First I am pleased this board uses the RtcEnterLowPowerStopMode function from Lora-net/LoRaMac-node and so am hoping to see exceptionally low power use.
I tried to get the board to use as little power as possible from a battery only connection, seeing if I could board to draw close to the claim of 1 uA. I could not get under 299 uA.
I used the STVD BoardTest project, compiling and loading with a cheap STLINK/V2 and free licence from Cosmic Software.
Tried the test examples including the three CSLEEEP, CSTDBY and CMCULPM tests in all modes with the three power, tx and rx LEDs removed. USB unplugged following setting mode (for example AT+CLSEEP=1,0 then unplug USB).
Lowest current with battery input set to 3.30 v was 300 uA for all four CSLEEP modes.
Tried bypassing ldo regulator using +3V3 pin direct but still 300 uA.
Pullups on i2c don't see to be the issue.
Puzzled if this is a software or hardware issue.