Go Down

Topic: MKR WiFi 1010 - Battery circuit operation (Read 4338 times) previous topic - next topic

Smile6905

It wasn't connected to the PC/USB at all, set using the test app I put together whereby the PC sends a packet via wifi to say set the reg/pin and the Arduino does the job.
Send me the registry sequence you use/write (I'm on mac and I don't have a PC, I'll check with my scope on my board and we can see if it works.


That sketch looks great btw - should be included in the standard examples for the board!
Thanks!

kierenj

It's the following, although the write doesn't "take" unless 5V/USB is not present, i.e. if it's plugged in, the register reverts to the default.

#define PMIC_ADDRESS  0x6B

Wire.beginTransmission(PMIC_ADDRESS);
Wire.write(0x01); // reg 01
Wire.write(0x2B); // 2B = OTG mode (1B = normal)
Wire.endTransmission();


pinMode(PIN_USB_HOST_ENABLE, OUTPUT); // should be the case from standard startup anyway..
digitalWrite(PIN_USB_HOST_ENABLE, LOW); // inverse of startup

Smile6905

#32
Aug 17, 2019, 11:28 am Last Edit: Aug 17, 2019, 03:54 pm by Smile6905 Reason: fixed some errors in code
It's the following, although the write doesn't "take" unless 5V/USB is not present, i.e. if it's plugged in, the register reverts to the default.

I have a small switch that removes power from the USB bus, so that the serial works on battery ;)

I have formatted the sketch a bit more:

//*
BQ SET OTG test
Trying 5V power boost on MKR WiFI1010

*/

#include <Wire.h>
#define PMIC_ADDRESS 0x6B


byte val;
byte BQ_REG[10] = { 0x01, 0x2, 0x03, 0x04, 0x05, 0x06,0x07,0x08, 0x09 };
byte OTG = 0x2B;

void setup() {
Serial.begin(115200);
while (!Serial) {
 ; // wait for serial port to connect. Needed for native USB
}

Wire.begin();

// Check battery status
analogReadResolution(12);
int sensorValue = analogRead(ADC_BATTERY);
float voltage = sensorValue * (4.208 / 4095.000);
     if (voltage < 3.000) { // BATLOWV REG04[1] = 1 {
     Serial.println("Battery voltage below 3.0V - Battery BOOST mode not allowed!");
     return;
   }
   else {
   Serial.print("Voltage: ");
   Serial.println(voltage);
   }
   
// Check watchdog timer status
Wire.beginTransmission(PMIC_ADDRESS);
Wire.write(BQ_REG[4]); // REG05
Wire.endTransmission();

Wire.beginTransmission(PMIC_ADDRESS);
Wire.requestFrom(PMIC_ADDRESS, 1);
Wire.endTransmission();

val = Wire.read();

Serial.print("Watchdog timer value is: ");
Serial.println(val);
     
  if (val != 154) {  // 154 DEC = 9A
     Serial.println("Watchdog timer is enabled, we're going to disable it now");
     Wire.beginTransmission(PMIC_ADDRESS);
     Wire.write(BQ_REG[4]); // REG05
     Wire.write(0x9A);  // Enable Termination, match ITERM, Set Watchdog timer to 00, Safety timer on, Fast Charge 8hrs
     Wire.endTransmission();
  }

// Set OTG High and OTG register REG01[4:5] to 10
pinMode(PIN_USB_HOST_ENABLE, OUTPUT);
digitalWrite(PIN_USB_HOST_ENABLE, HIGH); // Set OTG pin High

Wire.beginTransmission(PMIC_ADDRESS);
Wire.write(BQ_REG[0]);  // REG 01
Wire.write(OTG); // don't reset, normal watchdog, 10=OTG mode, 1011 = 3.5V min sys voltage
Wire.endTransmission();

}

void loop() {  // We dump now all the registries of the BQ chip

for (int r = 0; r < 9; r++) {
Wire.beginTransmission(PMIC_ADDRESS);
Wire.write(BQ_REG[r]);
Wire.endTransmission();

Wire.beginTransmission(PMIC_ADDRESS);
Wire.requestFrom(PMIC_ADDRESS, 1);
Wire.endTransmission();

val = Wire.read();

Serial.print("Register ");
Serial.print(BQ_REG[r]);
Serial.print(" = 0x");
 if (val<15)
{
 Serial.print("0");
}
Serial.print(val, HEX);
Serial.print("  Bits (0-7) :  ");

unsigned char byte = val;
unsigned char mask = 1;
unsigned char bits[8];

// Extract the bits
for (int i = 0; i < 8; i++) {
 // Mask each bit in the byte and store it
 bits = (byte >> i) & mask;

 Serial.print(bits);
 Serial.print(" ");
 }
 Serial.println(" ");
}
Serial.println(" ");
//pinMode(PIN_USB_HOST_ENABLE, OUTPUT); // should be the case from standard startup anyway..
//digitalWrite(PIN_USB_HOST_ENABLE, LOW); // inverse of startup

delay(10000);

}


Output with USB power on
Voltage: 4.17
Watchdog timer value is: 138
Watchdog timer is enabled, we're going to disable it now
Register 1 = 0x1B  Bits (0-7) :  1 1 0 1 1 0 0 0  
Register 2 = 0x00  Bits (0-7) :  0 0 0 0 0 0 0 0  
Register 3 = 0x11  Bits (0-7) :  1 0 0 0 1 0 0 0  
Register 4 = 0x9A  Bits (0-7) :  0 1 0 1 1 0 0 1  
Register 5 = 0x9A  Bits (0-7) :  0 1 0 1 1 0 0 1  
Register 6 = 0x03  Bits (0-7) :  1 1 0 0 0 0 0 0  
Register 7 = 0x0B  Bits (0-7) :  1 1 0 1 0 0 0 0  
Register 8 = 0x24  Bits (0-7) :  0 0 1 0 0 1 0 0  
Register 9 = 0x80  Bits (0-7) :  0 0 0 0 0 0 0 1

Output with USB power off
Voltage: 3.99
Watchdog timer value is: 138
Watchdog timer is enabled, we're going to disable it now
Register 1 = 0x2B  Bits (0-7) :  1 1 0 1 0 1 0 0  
Register 2 = 0x00  Bits (0-7) :  0 0 0 0 0 0 0 0  
Register 3 = 0x11  Bits (0-7) :  1 0 0 0 1 0 0 0  
Register 4 = 0x9A  Bits (0-7) :  0 1 0 1 1 0 0 1  
Register 5 = 0x9A  Bits (0-7) :  0 1 0 1 1 0 0 1  
Register 6 = 0x03  Bits (0-7) :  1 1 0 0 0 0 0 0  
Register 7 = 0x0B  Bits (0-7) :  1 1 0 1 0 0 0 0  
Register 8 = 0x00  Bits (0-7) :  0 0 0 0 0 0 0 0  
Register 9 = 0x80  Bits (0-7) :  0 0 0 0 0 0 0 1

I have noticed the following, REG1 not ok stays at 1B despite setting when on USB power, ok on battery to 2B, REG4 ok, REG8[6:7] = 00 As a result not good - Plus I'm getting intermittent watchdog error on REG9

So, still no 5V power out when on battery, last test would be to set OTG pin electrically High...  I need to find a USB cable to cut open and see what happens

kierenj

#33
Aug 17, 2019, 08:48 pm Last Edit: Aug 17, 2019, 08:52 pm by kierenj
Oh that's fantastic info, cool! Strange that you see 4.17V ish, not 5V, when plugged in.. was that from the 5V header? (Edit: oh I see, that's the battery ;))

I can see that for USB OTG devices, the USB ID pin (connected to PA18_OTG) is simply grounded. It would be interesting to see either OTG pulled high by force as you say, or also PA18_OTG simply grounded, although it does surprise me since the built-in firmware sets it HIGH by default.. wouldn't that draw too much current and do bad things?

Also - did you try it with digitalWrite(USB_HOST_ENABLE, LOW)? I see that's commented out and you're writing HIGH?

kierenj

#34
Aug 19, 2019, 09:20 pm Last Edit: Aug 19, 2019, 11:52 pm by kierenj
I'm starting to think that PA18 (from the schematic) is intended to be configured as an input. Pulled up by R21, and possibly then to ground via the USB ID pin (grounded for USB OTG cables), then the board could determine if USB OTG is intended.

But then, why would the SAMD21 firmware set the pin as an output and write it HIGH?

I have a replacement board now but don't want to try it for fear of shorting the IO I might be able to use further down the line..

Update: if I write LOW to USB_HOST_ENABLE, then literally attach OTG to 3.3V (wire from 3.3v header to mosfet output), I get a 5v rail!  (If I write or keep it at HIGH first, I get 5v too, but also a funky smell. :))

Update 2: the plot thickens. On both my original, and the replacement board, resistor R26 is absent, simply not connected. The board does not match the schematic.  I'm not sure what this means..

Smile6905

I'm starting to think that PA18 (from the schematic) is intended to be configured as an input. Pulled up by R21, and possibly then to ground via the USB ID pin (grounded for USB OTG cables), then the board could determine if USB OTG is intended.
I got the components... will test and come back to you shortly

kierenj

It's fine, it all works. I can get 5V on a battery with:

  writeReg(PMIC_REG01, OTG_MODE); // 0x2B
  pinMode(PIN_USB_HOST_ENABLE, OUTPUT);
  digitalWrite(PIN_USB_HOST_ENABLE, LOW);

My problem all along was that my boards did not have a resistor - R26 - present.

I can detect when USB power is added or removed, and toggle this on/off. There's a little more work to have it start charging when re-attached but pretty soon it'll be working as desired, I think.

Smile6905

My problem all along was that my boards did not have a resistor - R26 - present.

I have the same on 2 boards...

sslupsky

Hi Guys,  I came across your discussion of the bq24195.  A very nice read.

I have observed something I wanted to reach out and ask if others may have noticed.  I am using a MKR WAN 1310 which has the same BQ24195 circuitry as the MKR WIFI 1010.  I have been monitoring power consumption and noticed an anomaly when reading the system status register (REG08).  It appears that when I read this register, there is a spike in current that lasts for about 1 second.  At the moment, when sleeping my current is about 250uA.  I noticed that when I read the system status register, the current spikes to 1200uA and stays there for about 1 second.  The I2C transaction has long since ended (it lasts about 400us) and I have gone back to sleep.  But, for some reason, the bq24195 seems to be doing something and draws about 1mA, which frankly is an unbelievably high current consumption.

This behaviour would suggest it is not a good idea to poll the status of the bq24195 very often or even use it in host mode at all.

Has anyone else noticed this?

Smile6905

Hi Guys,  I came across your discussion of the bq24195.  A very nice read.
>> Sorry for not responding earlier... Thanks we spent quite some time debugging 3 boards with a missing resistor.. quite annoying but useful.

I have observed something I wanted to reach out and ask if others may have noticed.....
The only thing that I can think of is that it didn't really go to sleep...

You can try to add to your code something like this, to measure if there something executing keeping the MKR awake longer than you expected..

unsigned long start = micros();

// Here you start to measure your function
myFunction();

// At the end you see how long it really took
unsigned long end = micros();
unsigned long elapsed = end - start;
Serial.println(elapsed);

Not familiar with the 1310 specifically so I wouldn't know. Hope that helps
Cheers

sslupsky

I am quite certain the micro is going to sleep.

BTW, in case you are not aware, micros() does not increment during sleep because it uses the SysTick which is clocked by the cpu clock and is gated off during sleep.

If you get an opportunity, please measure the current as I mentioned above and let me know if you notice the same thing.

Thanks for the feedback.

Smile6905

BTW, in case you are not aware, micros() does not increment during sleep because it uses the SysTick which is clocked by the cpu clock and is gated off during sleep.

Yes I'm aware of you say... What I was trying to suggest you is:
Try to log the real time time elapsed before is really going to sleep4 and try to find discrepancies.

As you mentioned before...
"The I2C transaction has long since ended (it lasts about 400us) and I have gone back to sleep.  But, for some reason, the bq24195 seems to be doing something and draws about 1mA, which frankly is an unbelievably high current consumption."

So my assumption is that there is still something keeping the BQ chip up before going to sleep.

Other things to try:
1) When you finished your I2C read, force BATFET register off through REG07[5]
2) I don't know your application but you can try "BQ shipping mode", according to TI DS:
"The host has to disable the watchdog timer (REG05[5:4] = 00) and disable BATFET (REG07[5] = 1) at the same time." The only drawback is that you need power on VBUS to wake up from this state.

Hope it helps.




sslupsky

I am using the STANDBY mode of the mcu (I am not gating power to the board).  So, the system is operating and the power supply needs to operate continuously from either battery or usb power.

Regarding the timing measurements, I obtained those using an oscilloscope to observe the i2c transaction and the battery current.  So the measurements I have made should be reasonably accurate.

It appears to me that when the BQ24195 is configured to operate in host mode and you access the status register using the i2c bus it triggers some process inside the chip that increases the current for a very long period of time.  I use the mcu rtc to wake up periodically (every 125ms).  Thus, my observations lead me to believe polling this chip every time I wake up is a showstopper because of the large increase in average current.  Another conclusion you could draw from this is that you pretty much never want to read this register when running from the battery.

I am trying to determine as best I can what exactly the BQ24195 does when the status register is read.  Clearly, more than just sending the data over the i2c bus is happening.  Perhaps something can be turned off to prevent the internal process from running.  Unfortunately, the data sheet does not document the current consumption when the device is being accessed in host mode.

Go Up