Hi, I randomly picked one of the 5 main+cpu-boards (M15 + C44) I had not yet handed out to Michael and did boot it with latest Letux-4.10.4 and Letux-u-boot-2016.11 taken from the full Pyra prototype.
Here my observations: * booting is heavily dependent on good battery contact * if not, it may try to boot from VCHARGE power but that fails * then, I get errors like
U-Boot SPL 2016.11-00234-g095e2de (Feb 28 2017 - 10:11:15) OMAP5432-GP ES2.0
+++ stuck +++
OMAP5432-GP ES2.0 SDRAM: identified size not same as expected size identified: 0 expected: 40000000
spl:board_init_r()
spl_init() Trying to boot from MMC1 WARNING: DDR RAM is not working! (ff34ff78) Found LC15 V5.1 board_mmc_init called (vers = 51) MLO hard: gpio7 = eMMC soft: gpio82 = 0 (mmc1=eMMC) ctrl: gpio76 = 1 (ctrl=soft) MMC Device 0 not found spl: could not find mmc device. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
After some attempts making a better battery contact I could boot and got a login: Then I plugged in a computer and/or a power supply to the USB OTG pin and monitored the VBUS voltage reported by Palmas. Here an excerpt of the full log showing the important findings:
Debian GNU/Linux 8 letux console
letux login: root Password: Last login: Mon Mar 20 12:07:08 UTC 2017 on console Linux letux 4.10.4-letux+ #889 SMP PREEMPT Mon Mar 20 07:36:06 CET 2017 armv7l
root@letux:~# root@letux:~# ./charger Palmas System Voltage ===================== VSYS: 4035mV
Palmas Main Battery
volt: 4084mV ca. 82% type: 682mV VBUS: 45mV
there is no VBUS
VCHG: 4613mV
but VCHARGE
usb id: 984mV
The ID pin for OTG is floating
USB Charger /sys/class/power_supply/bq24297
type: USB online: 1 status: Charging
yes it is charging (a little) through the VCHARGE USB but limited to 500mA
mode: volt: 5000000uV current: 500000uA max_current: 500000uA ID:
Battery /sys/class/power_supply/bq27421-0
type: Battery present: 1 technology: Li-ion capacity: 93% status: Discharging
Of course operating the Pyra with 500mA charging and >500mA power demand makes the battery discharge
volt: 4114000uV
Next I plugged in an USB power supply:
root@letux:~# [ 72.656261] palmas-usb 48070000.i2c:palmas@48:palmas_usb: USB cable is attached ./charger Palmas System Voltage ===================== VSYS: 4029mV
Palmas Main Battery
volt: 4056mV ca. 79% temp: 33°C type: 680mV VBUS: 5352mV
VBUS is available. 5.3V can be considered a little high but still ok
VCHG: 4611mV usb id: 2869mV
still floating
USB Charger /sys/class/power_supply/bq24297
type: USB online: 1 status: Charging mode: volt: 5000000uV current: 500000uA max_current: 500000uA
Battery /sys/class/power_supply/bq27421-0
type: Battery present: 1 technology: Li-ion capacity: 93% status: Discharging level: Normal volt: 4118000uV
root@letux:~# [ 96.902581] palmas-usb 48070000.i2c:palmas@48:palmas_usb: USB cable is detached
cable unplugged
./charger Palmas System Voltage ===================== VSYS: 4024mV
Palmas Main Battery
volt: 4073mV ca. 81% current: 0mA temp: 33°C type: 674mV VBUS: 45mV VCHG: 4594mV usb id: 996mV
Palmas Backup battery
volt: 2516mV
USB Charger /sys/class/power_supply/bq24297
type: USB online: 1 status: Charging mode: volt: 5000000uV current: 500000uA max_current: 500000uA ID:
[ 99.715398] bq24296_update_input_current_limit(6)
look as if this comes too late to increase the current limit and maybe when unplugging VBUS and not when plugging.
=> bug in bq24297 driver (which is 200% hacked together)
root@letux:~# [ 100.973492] bq24296: VBUS became available [ 100.977925] bq24296_update_input_current_limit(6)
not it tries to increase the current limit.
Unfortunately I did stop here so there is no printout of the max_current: 500000uA property.
So in general:
* VBUS voltage reporting works as expected on this board combination * VBUS is detected * it tries to update the current limit of the bq24297 (but maybe not correctly) * discrepancy between charger and fuel gauge about charging/discharging is as expected
There is one major difference to other boards: the VCHARGE resistor R1208 is installed. Since the VIN input of the power switch has priority, charging current is always drawn from the console USB port. So increasing max_current might not really increase the available current if it is limited on the Host side.
And, the power switch never switches to VBUS as power source in this situation - unless R1208 is removed.
So we must be aware of this difference between a developer board where R1208 is removed and a mass market version where it is installed.
Otherwise it behaves as I have expected.
BR, Nikolaus
Am Tue, 21 Mar 2017 12:57:12 +0100 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
as I finally had the time to install a proper OS on my Pyra, I could do some tests as well.
My prototype has the latest patches from Nikolaus installed, no other chantes have been made.
Interestingly, VBUS on my system behaves exactly the same as on zmatts system.
The measurements are done like this:
cd /sys/bus/platform/devices/*:palmas*:gpadc/iio:device*/ printf '%-12s %4d mV\n' vbus `cat in_voltage10_input`
Here are my results:
1. USB-Serial out connected to my PC, 2.4A USB AC connected to USB OTG: ----------------------------------------------------------------------- ~1791mV (though it should report 5V), zmatt had about 1800mV here as well.
2. USB-Serial out connected to my PC, nothing on USB OTG: --------------------------------------------------------- ~1mV (which is correct).
3. No USB-Serial out, 2.4A USB AC connected to USB OTG: ------------------------------------------------------- ~1600mV (should still be about 5V), zmatt had about 1700mV here
4. No USB-Serial out, nothing on USB OTG: ----------------------------------------- ~1mV (which is correct).
So there are two results:
a) Even though PALMAS should report 5V on VBUS, it gets about 1,7V - 1,8V (tested on two boards)
b) Connecting a USB Cable on the USB Serial out port affects that voltage a bit as well (is this an issue? Or can this be ignored?)
A look into the schematics probably showed the reason of issue a) There's a 100k resistor between VBUS and VBUS_SENSE on the PALMAS. That one most probably changes the sensed voltage - so replacing it with 0R should fix that problem.
Hi, I randomly picked one of the 5 main+cpu-boards (M15 + C44) I had not yet handed out to Michael and did boot it with latest Letux-4.10.4 and Letux-u-boot-2016.11 taken from the full Pyra prototype.
Here my observations:
- booting is heavily dependent on good battery contact
- if not, it may try to boot from VCHARGE power but that fails
- then, I get errors like
U-Boot SPL 2016.11-00234-g095e2de (Feb 28 2017 - 10:11:15) OMAP5432-GP ES2.0
+++ stuck +++
OMAP5432-GP ES2.0 SDRAM: identified size not same as expected size identified: 0 expected: 40000000
spl:board_init_r()
spl_init() Trying to boot from MMC1 WARNING: DDR RAM is not working! (ff34ff78) Found LC15 V5.1 board_mmc_init called (vers = 51) MLO hard: gpio7 = eMMC soft: gpio82 = 0 (mmc1=eMMC) ctrl: gpio76 = 1 (ctrl=soft) MMC Device 0 not found spl: could not find mmc device. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
After some attempts making a better battery contact I could boot and got a login: Then I plugged in a computer and/or a power supply to the USB OTG pin and monitored the VBUS voltage reported by Palmas. Here an excerpt of the full log showing the important findings:
Debian GNU/Linux 8 letux console
letux login: root Password: Last login: Mon Mar 20 12:07:08 UTC 2017 on console Linux letux 4.10.4-letux+ #889 SMP PREEMPT Mon Mar 20 07:36:06 CET 2017 armv7l root@letux:~# root@letux:~# ./charger Palmas System Voltage ===================== VSYS: 4035mV
Palmas Main Battery
volt: 4084mV ca. 82% type: 682mV VBUS: 45mV
there is no VBUS
VCHG: 4613mV
but VCHARGE
usb id: 984mV
The ID pin for OTG is floating
USB Charger /sys/class/power_supply/bq24297
type: USB online: 1 status: Charging
yes it is charging (a little) through the VCHARGE USB but limited to 500mA
mode: volt: 5000000uV current: 500000uA max_current: 500000uA ID:
Battery /sys/class/power_supply/bq27421-0
type: Battery present: 1 technology: Li-ion capacity: 93% status: Discharging
Of course operating the Pyra with 500mA charging and >500mA power demand makes the battery discharge
volt: 4114000uV
Next I plugged in an USB power supply:
root@letux:~# [ 72.656261] palmas-usb root@48070000.i2c:palmas@48:palmas_usb: USB cable is attached ./charger Palmas System Voltage ===================== VSYS: 4029mV
Palmas Main Battery
volt: 4056mV ca. 79% temp: 33°C type: 680mV VBUS: 5352mV
VBUS is available. 5.3V can be considered a little high but still ok
VCHG: 4611mV usb id: 2869mV
still floating
USB Charger /sys/class/power_supply/bq24297
type: USB online: 1 status: Charging mode: volt: 5000000uV current: 500000uA max_current: 500000uA
Battery /sys/class/power_supply/bq27421-0
type: Battery present: 1 technology: Li-ion capacity: 93% status: Discharging level: Normal volt: 4118000uV
root@letux:~# [ 96.902581] palmas-usb root@48070000.i2c:palmas@48:palmas_usb: USB cable is detached
cable unplugged
./charger Palmas System Voltage ===================== VSYS: 4024mV
Palmas Main Battery
volt: 4073mV ca. 81% current: 0mA temp: 33°C type: 674mV VBUS: 45mV VCHG: 4594mV usb id: 996mV
Palmas Backup battery
volt: 2516mV
USB Charger /sys/class/power_supply/bq24297
type: USB online: 1 status: Charging mode: volt: 5000000uV current: 500000uA max_current: 500000uA ID:
[ 99.715398] bq24296_update_input_current_limit(6)
look as if this comes too late to increase the current limit and maybe when unplugging VBUS and not when plugging.
=> bug in bq24297 driver (which is 200% hacked together)
root@letux:~# [ 100.973492] bq24296: VBUS became available [ 100.977925] bq24296_update_input_current_limit(6)
not it tries to increase the current limit.
Unfortunately I did stop here so there is no printout of the max_current: 500000uA property.
So in general:
- VBUS voltage reporting works as expected on this board combination
- VBUS is detected
- it tries to update the current limit of the bq24297 (but maybe not
correctly)
- discrepancy between charger and fuel gauge about
charging/discharging is as expected
There is one major difference to other boards: the VCHARGE resistor R1208 is installed. Since the VIN input of the power switch has priority, charging current is always drawn from the console USB port. So increasing max_current might not really increase the available current if it is limited on the Host side.
And, the power switch never switches to VBUS as power source in this situation - unless R1208 is removed.
So we must be aware of this difference between a developer board where R1208 is removed and a mass market version where it is installed.
Otherwise it behaves as I have expected.
BR, Nikolaus
Am 23.03.2017 um 00:17 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Tue, 21 Mar 2017 12:57:12 +0100 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
as I finally had the time to install a proper OS on my Pyra, I could do some tests as well.
My prototype has the latest patches from Nikolaus installed, no other chantes have been made.
Interestingly, VBUS on my system behaves exactly the same as on zmatts system.
The measurements are done like this:
cd /sys/bus/platform/devices/*:palmas*:gpadc/iio:device*/ printf '%-12s %4d mV\n' vbus `cat in_voltage10_input`
Here are my results:
- USB-Serial out connected to my PC, 2.4A USB AC connected to USB OTG:
~1791mV (though it should report 5V), zmatt had about 1800mV here as well.
- USB-Serial out connected to my PC, nothing on USB OTG:
~1mV (which is correct).
- No USB-Serial out, 2.4A USB AC connected to USB OTG:
~1600mV (should still be about 5V), zmatt had about 1700mV here
- No USB-Serial out, nothing on USB OTG:
~1mV (which is correct).
So there are two results:
a) Even though PALMAS should report 5V on VBUS, it gets about 1,7V - 1,8V (tested on two boards)
b) Connecting a USB Cable on the USB Serial out port affects that voltage a bit as well (is this an issue? Or can this be ignored?)
A look into the schematics probably showed the reason of issue a) There's a 100k resistor between VBUS and VBUS_SENSE on the PALMAS. That one most probably changes the sensed voltage - so replacing it with 0R should fix that problem.
Yes, that is the fix. Remove R2607 and make R2606 a 0R. That is what the latest schematics and BOM given to GC says.
Hm. Did I simply forget to change/modify that resistor on some CPU boards and you happened to test those?
Then it is just a bug fixing bug...
Hi, I randomly picked one of the 5 main+cpu-boards (M15 + C44) I had not yet handed out to Michael and did boot it with latest Letux-4.10.4 and Letux-u-boot-2016.11 taken from the full Pyra prototype.
Here my observations:
- booting is heavily dependent on good battery contact
- if not, it may try to boot from VCHARGE power but that fails
- then, I get errors like
U-Boot SPL 2016.11-00234-g095e2de (Feb 28 2017 - 10:11:15) OMAP5432-GP ES2.0
+++ stuck +++
OMAP5432-GP ES2.0 SDRAM: identified size not same as expected size identified: 0 expected: 40000000
spl:board_init_r()
spl_init() Trying to boot from MMC1 WARNING: DDR RAM is not working! (ff34ff78) Found LC15 V5.1 board_mmc_init called (vers = 51) MLO hard: gpio7 = eMMC soft: gpio82 = 0 (mmc1=eMMC) ctrl: gpio76 = 1 (ctrl=soft) MMC Device 0 not found spl: could not find mmc device. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
After some attempts making a better battery contact I could boot and got a login: Then I plugged in a computer and/or a power supply to the USB OTG pin and monitored the VBUS voltage reported by Palmas. Here an excerpt of the full log showing the important findings:
Debian GNU/Linux 8 letux console
letux login: root Password: Last login: Mon Mar 20 12:07:08 UTC 2017 on console Linux letux 4.10.4-letux+ #889 SMP PREEMPT Mon Mar 20 07:36:06 CET 2017 armv7l root@letux:~# root@letux:~# ./charger Palmas System Voltage ===================== VSYS: 4035mV
Palmas Main Battery
volt: 4084mV ca. 82% type: 682mV VBUS: 45mV
there is no VBUS
VCHG: 4613mV
but VCHARGE
usb id: 984mV
The ID pin for OTG is floating
USB Charger /sys/class/power_supply/bq24297
type: USB online: 1 status: Charging
yes it is charging (a little) through the VCHARGE USB but limited to 500mA
mode: volt: 5000000uV current: 500000uA max_current: 500000uA ID:
Battery /sys/class/power_supply/bq27421-0
type: Battery present: 1 technology: Li-ion capacity: 93% status: Discharging
Of course operating the Pyra with 500mA charging and >500mA power demand makes the battery discharge
volt: 4114000uV
Next I plugged in an USB power supply:
root@letux:~# [ 72.656261] palmas-usb root@48070000.i2c:palmas@48:palmas_usb: USB cable is attached ./charger Palmas System Voltage ===================== VSYS: 4029mV
Palmas Main Battery
volt: 4056mV ca. 79% temp: 33°C type: 680mV VBUS: 5352mV
VBUS is available. 5.3V can be considered a little high but still ok
VCHG: 4611mV usb id: 2869mV
still floating
USB Charger /sys/class/power_supply/bq24297
type: USB online: 1 status: Charging mode: volt: 5000000uV current: 500000uA max_current: 500000uA
Battery /sys/class/power_supply/bq27421-0
type: Battery present: 1 technology: Li-ion capacity: 93% status: Discharging level: Normal volt: 4118000uV
root@letux:~# [ 96.902581] palmas-usb root@48070000.i2c:palmas@48:palmas_usb: USB cable is detached
cable unplugged
./charger Palmas System Voltage ===================== VSYS: 4024mV
Palmas Main Battery
volt: 4073mV ca. 81% current: 0mA temp: 33°C type: 674mV VBUS: 45mV VCHG: 4594mV usb id: 996mV
Palmas Backup battery
volt: 2516mV
USB Charger /sys/class/power_supply/bq24297
type: USB online: 1 status: Charging mode: volt: 5000000uV current: 500000uA max_current: 500000uA ID:
[ 99.715398] bq24296_update_input_current_limit(6)
look as if this comes too late to increase the current limit and maybe when unplugging VBUS and not when plugging.
=> bug in bq24297 driver (which is 200% hacked together)
root@letux:~# [ 100.973492] bq24296: VBUS became available [ 100.977925] bq24296_update_input_current_limit(6)
not it tries to increase the current limit.
Unfortunately I did stop here so there is no printout of the max_current: 500000uA property.
So in general:
- VBUS voltage reporting works as expected on this board combination
- VBUS is detected
- it tries to update the current limit of the bq24297 (but maybe not
correctly)
- discrepancy between charger and fuel gauge about
charging/discharging is as expected
There is one major difference to other boards: the VCHARGE resistor R1208 is installed. Since the VIN input of the power switch has priority, charging current is always drawn from the console USB port. So increasing max_current might not really increase the available current if it is limited on the Host side.
And, the power switch never switches to VBUS as power source in this situation - unless R1208 is removed.
So we must be aware of this difference between a developer board where R1208 is removed and a mass market version where it is installed.
Otherwise it behaves as I have expected.
BR, Nikolaus
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
On 23 March 2017 at 07:10, H. Nikolaus Schaller hns@goldelico.com wrote:
Yes, that is the fix. Remove R2607 and make R2606 a 0R.
Wrong resistors. That's for VBAT, not VBUS.
That is what the latest schematics and BOM given to GC says.
The 5.1 schematics show R2603 crossed out, but R2605 is still 100K.
Can you show where R2605 is located?
(Even better would be a PDF of both sides of the pcb, also so I know where to find stuff if I want to measure something)
Hi,
Am 23.03.2017 um 09:49 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 23 March 2017 at 07:10, H. Nikolaus Schaller hns@goldelico.com wrote: Yes, that is the fix. Remove R2607 and make R2606 a 0R.
Wrong resistors. That's for VBAT, not VBUS.
Ah, yes. You are right. Maybe I did the same mistake as when I applied the fixes... To forget that R2605 must change the value.
Or I did fix it only in some CPU boards and the design data for V5.2 and forgot about fixing it in the CPU boards handed out to ED.
That is what the latest schematics and BOM given to GC says.
It has been fixed for V5.2 and is in the V5.2 BOM as 0R.
The 5.1 schematics show R2603 crossed out, but R2605 is still 100K.
Should be and is 0R in V5.2 schematics.
Can you show where R2605 is located?
I have measured several CPU boards I have here. Some have 0R and some have 100k.
And I managed to test VBUS on 0R boards only.
So there is an unknown percentage of the 30 CPU boards we have built last time which is missing this known fix and hence reports wrong VBUS and makes other trouble.
(Even better would be a PDF of both sides of the pcb, also so I know where to find stuff if I want to measure something)
I usually give the raw file directly to the Fab. And they use the coordinates to program their pick&place, i.e. they rarely need a placement plan.
I don't have exactly documented that for the exact PCB you have in your hands. To find out I would have to match e-mails about sending production data with my git.
I could easily generate a PDF for the latest design data (V5.2) but that would deviate sometimes.
So here is a photo where the R2605 is (apparently a board where it is not fixed or you would see solder flux around R2605 as well):
BR, Nikolaus
Am 23.03.2017 um 10:59 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 23.03.2017 um 09:49 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 23 March 2017 at 07:10, H. Nikolaus Schaller hns@goldelico.com wrote: Yes, that is the fix. Remove R2607 and make R2606 a 0R.
Wrong resistors. That's for VBAT, not VBUS.
Ah, yes. You are right. Maybe I did the same mistake as when I applied the fixes... To forget that R2605 must change the value.
Or I did fix it only in some CPU boards and the design data for V5.2 and forgot about fixing it in the CPU boards handed out to ED.
That is what the latest schematics and BOM given to GC says.
It has been fixed for V5.2 and is in the V5.2 BOM as 0R.
The 5.1 schematics show R2603 crossed out, but R2605 is still 100K.
Should be and is 0R in V5.2 schematics.
here is the page how it is for V5.2:
Can you show where R2605 is located?
I have measured several CPU boards I have here. Some have 0R and some have 100k.
And I managed to test VBUS on 0R boards only.
So there is an unknown percentage of the 30 CPU boards we have built last time which is missing this known fix and hence reports wrong VBUS and makes other trouble.
(Even better would be a PDF of both sides of the pcb, also so I know where to find stuff if I want to measure something)
I usually give the raw file directly to the Fab. And they use the coordinates to program their pick&place, i.e. they rarely need a placement plan.
I don't have exactly documented that for the exact PCB you have in your hands. To find out I would have to match e-mails about sending production data with my git.
I could easily generate a PDF for the latest design data (V5.2) but that would deviate sometimes.
So here is a photo where the R2605 is (apparently a board where it is not fixed or you would see solder flux around R2605 as well):
<PastedGraphic-1.tiff>
Maybe this (V5.2) Pick&Place coordinate list also helps:
-
H. Nikolaus Schaller -
Matthijs van Duin -
Michael Mrozek