issue on PMU ADC on/off after XPowers library update

[gfilippi]

There was an update to the XPowers library in commit : Update XPowersLib

before this update I was used to measure the battery level in my loop by turning on/off "manually" the ADC with the calls: // Enable internal ADC detection PMU.enableBattDetection(); PMU.enableVbusVoltageMeasure(); PMU.enableBattVoltageMeasure(); PMU.enableSystemVoltageMeasure();

and the counter part: PMU.disableBattDetection(); PMU.disableVbusVoltageMeasure(); PMU.disableBattVoltageMeasure(); PMU.disableSystemVoltageMeasure();

Basically I was turning on ADC, do the measure, turn off ADC, like this:

loop() { (...) pmuSetAdcON(); vbat = PMU.getBattVoltage(); vbus = PMU.getVbusVoltage(); pmuSetAdcOFF(); (...) }

=== ISSUE: after the library update this does not work anymore. It work correctly the very first time in the loop, but all the next probe event (in the same loop) are always reporting the same meaure .. not updating with the correct values.

This was working just fine before the update ..

any idea about fixing this use case?

thanks

[gfilippi]

another issue related to this: I'm not using the camera connector and so I'm using ALDO1 as power source for an external MAX31850K to read a thermocouple. (ALD01 is set to 3.3v in my case)

If I keep the PMU measure enabled I do get a very "unstable" reading from the MAX31850K sensor.

If I disable the PMU measures ... the reading of the sensor is super precise (!)

it seems like the pmu reading ADC is affecting the output voltages on the LDO.

but if this is the case ... we need a way to turn them off/on programmatically.

please help .. I'm running out of ideas since this was all working fine before the library update.

[lewisxhe]

1. After closing, the read value is still the last recorded value, and the PMU will not refresh the data register.

2. Updating XPowersLib did not change any ADC related parts, you can check the commit information

3. Reading the ADC will not affect the voltage of the LDO, which I have checked with an oscilloscope.

[gfilippi]

thanks a lot for your reply!

I will debug more .. but may I ask you to provide an example where we "open/measure/print voltage/close" in a loop each second or so? I want to make sure I'm not doing anything wrong.

[lewisxhe]

Did you see if this helps you?

[gfilippi]

this is a good reference, thanks a lot. I've already identified one issue on my side related to the max31850 connection (parasidic power) and I'm now checking again if adc on/off is making a difference. I will report back as soon as I have a clear understanding of my problem (because I'm sure the problem is on my side...)

thanks a lot for your help!

[gfilippi]

one favor while I'm trying to debug this issue using MAX31850 for reading temperatures .... could you please confirm that GPIO45 is "free" for the user? I'm using GPIO45 as a data line for the one-wire protocol of the sensor ... just want to make sure I'm not going to interfere with something else (checking the schematic seems free to me...)

thanks

[lewisxhe]

single bus? Please do not use GPIO40 or above, please replace it with GPIO22 or below IO, I remember that GPIO above GPIO22 will have problems with single bus

[gfilippi]

ouch... yes I'm using MAX31850 which is one-wire protocol (I suppose you call it single bus..)

so ... If I'm not using the camera all the GPIO9-GPIO14 (exposed on the left side of the board) can be used for this sensor, correct? (meaning one pin in that group)

[lewisxhe]

Yes, try to use GPIO below GPIO22

[gfilippi]

ok, noted.

about this problem (specific to the MAX31850): in my setup I'm measuring the temperature via the MAX31850 every 15 seconds, continuously.

I started to see "random" problems where the temperature was measured with a wrong value, and I that time I was thinking a power issue due to the library update.

thanks to your support I decided to debug the sensor and I noticed that when the temperature was wrong the data was actually "correct" over the bus, meaning the CRC of the one-wire read from the sensor was OK.

So I started to suspect once again the power stage, because I'm turning ON/OFF power every 15 sec (with a delay of 500ms to let the sensor stabilize itself). I'm using ALDO2 output (at 3.3v) only for this sensor.

Right now I'm testing a while loop to make sure the pmu is "turning ON" correctly the output like this:

void pmuMAX31850VoltageON()
{
    PMU.setALDO2Voltage(3300);
    PMU.enableALDO2();
    while(!(PMU.isenabledALDO2()))
    {
       PMU.enableALDO2();
      delay(50);
    }
}

I've been running for 24h now and I did not see the "random" wrong temperature ... (using GPIO45 for one-wire data line)

=== I'll test for some more time and then I'll move the data line from GPIO45 to GPIO21

thanks a lot for your help

[gfilippi]

so the issue of "wrong temperature" came out again towards end of the battery life (3.76v) ... which let me thinking ...

I'm using ALDO2 to power the MAX31850 sensor .. but I set the ALDO2 to 3.3v ... do you know the minimum "voltage drop" for the LDOs of the AXP2101? I'm looking at the datasheet but I can't find it ... I might have to measure this before moving GPIO

[gfilippi]

hello, after few days of logging I can say that the issue is related to the MAX31850 itself. The sensor is sensitive to EMI and I was not powering off the modem while taking the temperature measurements. Now I make sure to power of both wifi/BT and simcom modem 1s before taking the temperature measure and every single value is correct (tested for a long, long time).

[gfilippi]

issue was not related to the pmu or lilygo library