Hi Tony,
Am 30.09.2016 um 19:09 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160929 06:45]:
Am 27.09.2016 um 18:44 schrieb Tony Lindgren tony@atomide.com: Might be still checking on Pyra if it behaves better with ehci-omap and ohci-omap3 unloaded.
We have done measurements today and it does not make a visible difference, at least when rmmod-ing after boot.
OK so it seems ehci and the hub just cause extra power consumption and that's enough to make omap5-uevm fail for me at 4.5V supply.
But we have found a completely different explanation for the Pyra and EVM problems.
The first observation was that the cables between power supply and device/board have some resistance. It ist typically 0.5 - 1 Ohm. So this means a voltage drop of 0.5 - 1 V at 1A. If the system draws 2A (can happen @1.5GHz) the voltage drop is higher.
OK
For the Pyra we use the bq24297 charger chip. What we have learned today is that it not only has a programmable current limitation (to comply with 100/500/900 mA standard USB sources and 1A/2A power supplies), but it also has a minimum voltage level where it switches to "supplement" mode. Then both the power supply and the battery provide energy to the OMAP5. This probably means that using standard USB cabeling it is not possible to charge the battery while the OMAP5 is running at 200% load.
Might be still possible with a charging USB hub after charger negotiation :)
Now, this minimum voltage is 4.36V by hardware default. If the OMAP draws too much current and the USB power cable has a high resistance (something which is very different between all the users), this voltage level is undercut. If we want to operate the system without battery, the bq24297 seems to switch off or cut off the current or whatever. This might just be a very short glitch so that the Palmas does not simply turn off but makes the OMAP5 hang.
We found this because the Pyra did boot and run stable if the power supply was raised to 5.6V or above... This is beyond USB specs of course but the bq24297 is forgiving.
Oh OK that sounds like the root cause for the issue then.
The good thing is that we just have to patch MLO/U-Boot a little so that it not only increases the current limit wide enough but also reduces this minimum voltage.
AFAIK for USB, you should only increase the USB charger limit based on the charger and USB peripheral negotiation depending what you're connected to.
Yes in normal operation.
This is also the reason why some smartphones or tablets do not charge if plugged into a standard PC USB port.
We do this increasing without negotiation only if there is no battery installed, which indicates a lab setup.
In normal operation some battery monitor could detect that the charger is going to its limits and the battery is still discharging and show an alert to check cables and wall charger.
This is what I have seen for some such devices.
The OMAP5 EVM has something similar. It uses some tps54426 DC/DC converter between the power jack and the Palmas power input. This is quite similar to what the bq24297 does.
OK
Now the data sheet defines the tps54426 as 4.5V - 18 V converter (unfortunately it does not exactly define the lower limit and what happens if it is undercut).
But again we have a significant lower limit on input voltage which depends on power consumption of the OMAP5 board and the resistance of the supply cable! Here we know that it also helps to increase the input voltage as Roy has recently demonstrated.
Yes for many USB cables I've noticed they only provide current up to 600mA when charging. The cheapo $10/10€ USB charge monitors help debugging this :)
In fact USB2 cables are required to support 500 or 900mA only. Only chargers must be able to carry a higher current. Or USB3 cables.
So we only have to modify the Pyra U-Boot code to verify our theory.
And, if someone could please share the IGEP schematics or look into them how it derives the Palmas power input from the DC jack, we could cross-check why the IGEP appears not to show such problems if run from 5V supplies.
So I think we have found the hardware mechanism which can make the Pyra and EVM instable.
OK good to hear!
We are still testing if it is indeed true...
BR, Nikolaus