We’re in the midst of developing a product based on the B523 SoM with fuelgauge and PMIC as recommended.
The problem is however that DeviceOS seems to randomly detect the PMIC (no real pattern in when), which makes commands such as System.powerSource() and System.batteryState() return 0 (i.e. unknown), this also makes commands such as power.getInputCurrentLimit() return default values. However, when scanning I2C address, the PMIC pops up on its’ address 0x6B
Scanning...
I2C device found at address 0x32 !
I2C device found at address 0x36 !
I2C device found at address 0x44 !
I2C device found at address 0x6B !
//Switching back to factory defaults
0000056340 [app] INFO: Current PMIC settings:
0000056341 [app] INFO: VIN Vmin: 3880
0000056342 [app] INFO: VIN Imax: 500
0000056343 [app] INFO: Ichg: 1024
0000056343 [app] INFO: Iterm: 4112
0000056345 [app] INFO: Power source: unknown
0000056345 [app] INFO: Battery state: unknown
0000056345 [app] INFO: Battery charge: -1.000000
Anyone seen this behavour before? When it detects it, we’re unable to change PMIC settings using the System API.
Can you confirm that I2C communication to your other devices on the bus is reliable?
What are these other devices?
What speed have you set your bus for?
Have you tried a different speed setting?
What value pull-ups have you placed?
Can you confirm that I2C communication to your other devices on the bus is reliable?
Yes, we have multiple sensors running on the same line, which is stable. However, we’ve tried shutting them all off (using mosfets)
What are these other devices?
By devices, I mean physical environmental sensors that use I2C for communication
What speed have you set your bus for?
We use the default clock speed at 100KHz
Have you tried a different speed setting?
I have just tried setting it to CLOCK_SPEED_400KHZ, with no change (both normal and fast mode is supported according to BQ24195 datasheet).
What value pull-ups have you placed?
I will have to check, but I believe it’s 4k7
Additional
I am wondering however whether the BQ24195 returns to default mode for some reason? Not staying host mode/slave mode. If you look at the datasheet https://www.ti.com/lit/ds/symlink/bq24195.pdf and go to the chapter “Device Functional Modes”, it describes this functionality with a watchdog timer. If the watchdog timer expires, it goes into default mode. I can see the red led blink rapidly, so I believe the PMIC is still working its’ magic (and it’s powered from USB as well).
An additional note is that we see I2C address for sensors that are shut off using the mosfet (confirmed with multimeter), which I am still scratching my head about. But what if it’s the same we see here, that the I2C address is shown, but we’re unable to communicate with it. However, this does not explain the correctly flashing red charge status LED.
You need to check the pull up resistance with all devices combined.
The Gen3 devices have built in 10k pullups or something close to that that are built in which caused me issues also until I found out about the internal pull-ups.
Yes, we traced it down to the pull-ups in combination with a sensor on the same I2C lines that couldn’t have a pin left floating.
One problem down, and we ran right into another We have added a status LED on A6, however this is being used as a LOW_BAT_UC interrupt by the system power manager, so that also created some problems on our PMIC. However, I’ve compiled a local build where this interrupt is detached that works in the DeviceOS - but how can we OTA with this “branch” of DeviceOS? For now, I simply detach the interrupt every loop.
We have deployed some units to the field, and they are charging very slowly, but this could be due to the few hours of sunlight during winter time here - It works fine with a power supply.
I have attached a picture of the unit, since it’s always more fun to know what we’re talking about.
We have added a status LED on A6, however this is being used as a LOW_BAT_UC interrupt by the system power manager, so that also created some problems on our PMIC. However, I’ve compiled a local build where this interrupt is detached that works in the DeviceOS - but how can we OTA with this “branch” of DeviceOS? For now, I simply detach the interrupt every loop.