here a short update of the hardware test results (the 3.17 kernel git is updated accordingly trying to make things work).
First, let's start with what has already been tested and is working fine:
• Keyboard-Backlight LEDs • Shoulder Buttons • Nub buttons • Nubs (Position etc.) • Keyboard • Sensor: BMP180 (digital barometric pressure sensor) • DC/DC-Converter for the USB-Hosts ports • magnetic lid detector
Not yet tested:
• RGB-LEDs
have been fixed (hardware issue). Just one flaw: the red LEDs glow a little even if turned off. We need to rewrite the tca6424 driver so that gpios can be configured as "open drain" outputs: http://projects.goldelico.com/p/gta04-kernel/issues/658/
• Stresstest VBUS
the vbus voltage breaks down at ~11 Ohm load which means 450 mA. This is a little lower than expected and required (should be at least 500 mA - better 1A). vbus can be turned on/off through GPIOs. The next version of the main board will indicate over-current (either through red LEDs and/or GPIOs)
• Microphone-Detect-Switch
the TS3A225E works fine if accessed through I2C. A new test script is here: http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pyra-kernel.git;a=commit;h=3... It even sends the mic_present signal to the TCA6424 which even raises the INT GPIO (can be checked by exporting it and reading from /sys). But the kernel does not handle changes as IRQ and they don't arrive in the extcon-gpio driver as expected.
• CPU-Reset-Logic (LSH-BOTTOM + Poweron)
this circuit is broken and needs to be redesigned.
• Charger-Bypass
works (except some insignificant issue which can be solved later - if at all).
• FTDI232 (Linux console)
responds on the USB side.
• Charger
the charger chip behaves sane and expected (as far as it could be tested without real battery and system consuming high energy). A preliminary I2C driver for the bq2429x has been added. But the charger should also work without driver.
• Vibration motor, Microphone, Speakers
not yet tested.
• Modem-USB, Modem-Ignite, GPS
not yet tested (was already tested in the previous design except GPS and new functions like new SIM card reader).
• INA231 (for checking modem status/power)
a hardware issue prevents complete test.
• Fuel Gauge(s)
bq27200 responds but delivers unreasonable values. bq27421 does not respond.
• Other sensors
Can't be tested yet (as we need the CPU-Board and/or the next revision of the motherboard: • HDMI • eSATA • USB-OTG 2/3 • Audio • WLAN/BT • Display connected to the mainboard
More tests to be done beginning of next week. And I have not yet continued to develop/test the Displays.
BR, Nikolaus
Hi,
On Thu, Sep 11, 2014 at 3:05 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
here a short update of the hardware test results (the 3.17 kernel git is updated accordingly trying to make things work).
First, let's start with what has already been tested and is working fine:
• Keyboard-Backlight LEDs • Shoulder Buttons • Nub buttons • Nubs (Position etc.) • Keyboard • Sensor: BMP180 (digital barometric pressure sensor) • DC/DC-Converter for the USB-Hosts ports • magnetic lid detector
Not yet tested:
• RGB-LEDs
have been fixed (hardware issue). Just one flaw: the red LEDs glow a little even if turned off. We need to rewrite the tca6424 driver so that gpios can be configured as "open drain" outputs: http://projects.goldelico.com/p/gta04-kernel/issues/658/
I hope such setup doesn't waste power..
• Stresstest VBUS
the vbus voltage breaks down at ~11 Ohm load which means 450 mA. This is a little lower than expected and required (should be at least 500 mA - better 1A). vbus can be turned on/off through GPIOs. The next version of the main board will indicate over-current (either through red LEDs and/or GPIOs)
We had lots of issues with this on pandora, some of which were never resolved. First MWeston found that some rotational USB drives use excessive current while spinning up, > 1A. Pandora can do a bit over 1A, but still there were reports on the forum that some drives don't start up without powered hub. Not much can be done about that I guess, but still I think we need to be able to supply at least something close to 1A and surely not 450mA.
Then there was an issue that the LCD was powered from the same power supply as VBUS, and connecting a drive would make the backlight flicker wildly, so we need a dedicated supply (maybe it already is in your design, I don't know how to check).
Later it was found that overcurrent protection doesn't actually work. I'm not sure if it was ever fixed.. There was even report of a burned board from USB HDD user. The LCD got it's own supply for rebirth.
Last and most annoying thing is that turning off VBUS over GPIO on pandora wastes more power than the whole OMAP3 with LCD off (no idea why), so we never turn off VBUS on pandora.
I really hope it will all work properly this time..
• Microphone-Detect-Switch
the TS3A225E works fine if accessed through I2C. A new test script is here: http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pyra-kernel.git;a=commit;h=3... It even sends the mic_present signal to the TCA6424 which even raises the INT GPIO (can be checked by exporting it and reading from /sys). But the kernel does not handle changes as IRQ and they don't arrive in the extcon-gpio driver as expected.
• CPU-Reset-Logic (LSH-BOTTOM + Poweron)
this circuit is broken and needs to be redesigned.
• Charger-Bypass
works (except some insignificant issue which can be solved later - if at all).
Could you explain what that is? Powering the device without battery perhaps?
• FTDI232 (Linux console)
responds on the USB side.
Again, I hope it doesn't waste power..
• Charger
the charger chip behaves sane and expected (as far as it could be tested without real battery and system consuming high energy). A preliminary I2C driver for the bq2429x has been added. But the charger should also work without driver.
• Vibration motor, Microphone, Speakers
not yet tested.
• Modem-USB, Modem-Ignite, GPS
not yet tested (was already tested in the previous design except GPS and new functions like new SIM card reader).
• INA231 (for checking modem status/power)
a hardware issue prevents complete test.
• Fuel Gauge(s)
bq27200 responds but delivers unreasonable values. bq27421 does not respond.
• Other sensors
With pandora experience I feel uneasy with all these sensors.. I hope they all can be turned off or have good power management states, as on pandora nubs can't be turned off without wasting lots of power, again for unknown reasons..
Can't be tested yet (as we need the CPU-Board and/or the next revision of the motherboard: • HDMI • eSATA • USB-OTG 2/3 • Audio • WLAN/BT
I guess audio is still to be selected, like BT/WLAN?
• Display connected to the mainboard
More tests to be done beginning of next week. And I have not yet continued to develop/test the Displays.
BR, Nikolaus
Am Fri, 12 Sep 2014 16:58:06 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
Later it was found that overcurrent protection doesn't actually work. I'm not sure if it was ever fixed..
I think so, the Rebirth Pandora had extra protection stuff added to the USB port. With CC Pandoras, you could even get a small electrical shock from the USB Port (and fry the Port with that), but that doesn't happen anymore on the later Pandoras.
I really hope it will all work properly this time..
We need to check that upfront, now we know what to look for, which helps.
• FTDI232 (Linux console)
responds on the USB side.
Again, I hope it doesn't waste power..
It shouldn't. At least on the EVM it gets it's power from the PC. As soon as you connect it to your PC (without connecting the EVM to any power source), the small LED lights up on the EVM and the PC finds the USB to Serial adaptor.
bq27200 responds but delivers unreasonable values. bq27421 does not respond.
• Other sensors
With pandora experience I feel uneasy with all these sensors.. I hope they all can be turned off or have good power management states, as on pandora nubs can't be turned off without wasting lots of power, again for unknown reasons..
I'm all for turning off!
On Fri, Sep 12, 2014 at 5:59 PM, Michael Mrozek mrozek@openpandora.org wrote:
Am Fri, 12 Sep 2014 16:58:06 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
Later it was found that overcurrent protection doesn't actually work. I'm not sure if it was ever fixed..
I think so, the Rebirth Pandora had extra protection stuff added to the USB port. With CC Pandoras, you could even get a small electrical shock from the USB Port (and fry the Port with that), but that doesn't happen anymore on the later Pandoras.
I really hope it will all work properly this time..
We need to check that upfront, now we know what to look for, which helps.
• FTDI232 (Linux console)
responds on the USB side.
Again, I hope it doesn't waste power..
It shouldn't. At least on the EVM it gets it's power from the PC. As soon as you connect it to your PC (without connecting the EVM to any power source), the small LED lights up on the EVM and the PC finds the USB to Serial adaptor.
That LED doesn't guarantee that there is no leakage current of some sorts going from OMAP to the chip while the chip is unpowered from the USB side (which will be most common state).
Hi Notaz,
Am 12.09.2014 um 18:42 schrieb Grazvydas Ignotas notasas@gmail.com:
On Fri, Sep 12, 2014 at 5:59 PM, Michael Mrozek mrozek@openpandora.org wrote:
Am Fri, 12 Sep 2014 16:58:06 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
Later it was found that overcurrent protection doesn't actually work. I'm not sure if it was ever fixed..
I think so, the Rebirth Pandora had extra protection stuff added to the USB port. With CC Pandoras, you could even get a small electrical shock from the USB Port (and fry the Port with that), but that doesn't happen anymore on the later Pandoras.
I really hope it will all work properly this time..
We need to check that upfront, now we know what to look for, which helps.
that is what I am doing with the stress-tests.
We use a TPS2505 "INTEGRATED DUAL USB SWITCHES, BOOST CONVERTER AND LDO" which is designed for that purpose.
It has • Adjustable Independent USB Current Limit – 100 mA to 1100 mA • 5.1-V, 1100-mA boost converter, a 200-mA, 3.3-V LDO linear regulator and dual USB 2.0 compliant power outputs with independent output switch enable, current limit, and over-current fault reporting.
I have just checked that the resistors which control the current limit are chosen more for 500 mA. If I remember this correctly it comes from some reference design.
So I will simply choose a different resistor value so that we can draw 1 A from each of the USB ports (but not more than 1.1A in total). Then of course there might be a different limit - if the battery and DC/DC converter can provide enough energy/current at 3.3V battery voltage…
That is something we have to find out with the next prototype.
• FTDI232 (Linux console)
responds on the USB side.
Again, I hope it doesn't waste power..
It shouldn't. At least on the EVM it gets it's power from the PC. As soon as you connect it to your PC (without connecting the EVM to any power source), the small LED lights up on the EVM and the PC finds the USB to Serial adaptor.
We have the same on the Pyra mainboard (except the LED). The FTDI is powered by the host cable and does not draw any energy from the battery.
That LED doesn't guarantee that there is no leakage current of some sorts going from OMAP to the chip while the chip is unpowered from the USB side (which will be most common state).
No, but there is a TXB0102 level shifter which protects against this issue (no external power to the FTDI but OMAP powered up).
BR, Nikolaus
Am 12.09.2014 um 16:59 schrieb Michael Mrozek mrozek@openpandora.org:
Am Fri, 12 Sep 2014 16:58:06 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
Later it was found that overcurrent protection doesn't actually work. I'm not sure if it was ever fixed..
I think so, the Rebirth Pandora had extra protection stuff added to the USB port. With CC Pandoras, you could even get a small electrical shock from the USB Port (and fry the Port with that), but that doesn't happen anymore on the later Pandoras.
as said the TPS2505 is designed for exactly this application (and I think it is used in many notebooks and tablets).
Each output can be controlled separately and the TPS2505 has an enable input. If disabled the chip is specified to draw only 5uA from the battery.
I really hope it will all work properly this time..
We need to check that upfront, now we know what to look for, which helps.
• FTDI232 (Linux console)
responds on the USB side.
Again, I hope it doesn't waste power..
It shouldn't. At least on the EVM it gets it's power from the PC. As soon as you connect it to your PC (without connecting the EVM to any power source), the small LED lights up on the EVM and the PC finds the USB to Serial adaptor.
bq27200 responds but delivers unreasonable values. bq27421 does not respond.
• Other sensors
With pandora experience I feel uneasy with all these sensors.. I hope they all can be turned off or have good power management states,
yes they have ultra-low power states.
as on pandora nubs can't be turned off without wasting lots of power, again for unknown reasons..
The Pyra design is much different from the Pandora. And uses a different set of experiences so that you can’t draw conclusions from Pandora problems to still exist in the Pyra.
It is much more likely that we will see other problems in areas we have not yet though of. But we will see and fix them.
I'm all for turning off!
yes they can. They are (mostly) known from the GTA04 design and with a 1200 mAh battery it is even more important do be able to turn off sensors that are not needed. And turning off does not need a transistor+gpio but just writing a „sleep“ command through I2C.
If they draw significant current at all. E.g. the BMP180 draws 650uA in full operation. And has low-power standby modes. So this would mean ~9000 hours…
And if I remember correctly the other sensors are also in the 2-3 mA range. So this is nothing to worry about. More problematic is for example the eSATA transceiver chip. It is said to draw 1mA even if disabled through the enable-input. Therefore I have already added another switch transistor.
BR, Nikolaus
Am 12.09.2014 um 15:58 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
On Thu, Sep 11, 2014 at 3:05 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
here a short update of the hardware test results (the 3.17 kernel git is updated accordingly trying to make things work).
First, let's start with what has already been tested and is working fine:
• Keyboard-Backlight LEDs • Shoulder Buttons • Nub buttons • Nubs (Position etc.) • Keyboard • Sensor: BMP180 (digital barometric pressure sensor) • DC/DC-Converter for the USB-Hosts ports • magnetic lid detector
Not yet tested:
• RGB-LEDs
have been fixed (hardware issue). Just one flaw: the red LEDs glow a little even if turned off. We need to rewrite the tca6424 driver so that gpios can be configured as "open drain" outputs: http://projects.goldelico.com/p/gta04-kernel/issues/658/
I hope such setup doesn't waste power..
Only the current one. If the outputs are controlled through I2C as open-drain, they don’t waste power if the LEDs are turned off. The problem is that they can’t be turned completely off through the current linux driver.
What the TCA6424 driver currently does:
set-direction: make it input or totem-pole output set-value: set output to 0V or 1.8V
what we need is some property "oc-outputs = <3, 4, 7, 11>" in the DT
set-direction: make it input or OC/OD output set-value: 0: make it output and 0 value (pull down), 1: make it input (open collector/drain)
• Stresstest VBUS
the vbus voltage breaks down at ~11 Ohm load which means 450 mA. This is a little lower than expected and required (should be at least 500 mA - better 1A). vbus can be turned on/off through GPIOs. The next version of the main board will indicate over-current (either through red LEDs and/or GPIOs)
We had lots of issues with this on pandora, some of which were never resolved. First MWeston found that some rotational USB drives use excessive current while spinning up, > 1A. Pandora can do a bit over 1A, but still there were reports on the forum that some drives don't start up without powered hub. Not much can be done about that I guess, but still I think we need to be able to supply at least something close to 1A and surely not 450mA.
Then there was an issue that the LCD was powered from the same power supply as VBUS, and connecting a drive would make the backlight flicker wildly, so we need a dedicated supply (maybe it already is in your design, I don't know how to check).
Later it was found that overcurrent protection doesn't actually work. I'm not sure if it was ever fixed.. There was even report of a burned board from USB HDD user. The LCD got it's own supply for rebirth.
Last and most annoying thing is that turning off VBUS over GPIO on pandora wastes more power than the whole OMAP3 with LCD off (no idea why), so we never turn off VBUS on pandora.
I really hope it will all work properly this time..
• Microphone-Detect-Switch
the TS3A225E works fine if accessed through I2C. A new test script is here: http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pyra-kernel.git;a=commit;h=3... It even sends the mic_present signal to the TCA6424 which even raises the INT GPIO (can be checked by exporting it and reading from /sys). But the kernel does not handle changes as IRQ and they don't arrive in the extcon-gpio driver as expected.
• CPU-Reset-Logic (LSH-BOTTOM + Poweron)
this circuit is broken and needs to be redesigned.
• Charger-Bypass
works (except some insignificant issue which can be solved later - if at all).
Could you explain what that is? Powering the device without battery perhaps?
The charger bypass forwards the 5V VBUS from the secondary USB port to the OTG port so that connecting a wall charger to the secondary port can also charge the battery.
The small issue is that if you power the OTG port by a wall charger you will see 5V on the secondary port - which isn’t an OTG. And the circuit should have interrupted that path - but did some latch-up.
But since it only happens if you have 5V on the OTG port through an external charger it is IMHO insignificant.
Anyways, while working on the CPU board design I found that we already have a 5V step-up-converter for the OTG mode on the CPU board (provided through the Palmas chip). This should allow to use a different battery charger which has two separate power inputs (BQ24161B) instead of a built-in OTG power converter like the BQ24297. So if we replace the charger chip the problem mentioned above will simply disappear (any may be replaced by other problems I don’t see yet).
• FTDI232 (Linux console)
responds on the USB side.
Again, I hope it doesn't waste power..
• Charger
the charger chip behaves sane and expected (as far as it could be tested without real battery and system consuming high energy). A preliminary I2C driver for the bq2429x has been added. But the charger should also work without driver.
• Vibration motor, Microphone, Speakers
not yet tested.
• Modem-USB, Modem-Ignite, GPS
not yet tested (was already tested in the previous design except GPS and new functions like new SIM card reader).
• INA231 (for checking modem status/power)
a hardware issue prevents complete test.
• Fuel Gauge(s)
bq27200 responds but delivers unreasonable values. bq27421 does not respond.
• Other sensors
With pandora experience I feel uneasy with all these sensors.. I hope they all can be turned off or have good power management states, as on pandora nubs can't be turned off without wasting lots of power, again for unknown reasons..
Can't be tested yet (as we need the CPU-Board and/or the next revision of the motherboard: • HDMI • eSATA • USB-OTG 2/3 • Audio • WLAN/BT
I guess audio is still to be selected, like BT/WLAN?
Plan for Audio: TWL6040 (placed on the CPU board!) since it has the best and easiest system integration with OMAP5 and has all required features (incl. built-in amplifiers). Can be replaced together with the CPU. And, it allows to have more digital signal processing (easier to shield analog signals from noise, especially GSM buzz). Potentiometer will get an ADC to digitally control attenuation. Can also be (mis)used as another game control :) And attenuation can alternatively/additionally controlled by on-screen sliders or +/- buttons giving maximum flexibility in user interface.
Plan for BT/WLAN: WiLink6 WG7351 since the WiLink8 WG78xx modules by JorJin have less features and are bigger and unclear if they are really available.
BR, Nikolaus
On Sun, Sep 14, 2014 at 11:56 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Am 12.09.2014 um 15:58 schrieb Grazvydas Ignotas notasas@gmail.com:
I guess audio is still to be selected, like BT/WLAN?
Plan for Audio: TWL6040 (placed on the CPU board!) since it has the best and easiest system integration with OMAP5 and has all required features (incl. built-in amplifiers). Can be replaced together with the CPU. And, it allows to have more digital signal processing (easier to shield analog signals from noise, especially GSM buzz). Potentiometer will get an ADC to digitally control attenuation. Can also be (mis)used as another game control :) And attenuation can alternatively/additionally controlled by on-screen sliders or +/- buttons giving maximum flexibility in user interface.
From my listening tests, TWL6040 sounds really bad on the EVM though,
but I don't have any alternatives to suggest.
Plan for BT/WLAN: WiLink6 WG7351 since the WiLink8 WG78xx modules by JorJin have less features and are bigger and unclear if they are really available.
WG7351 uses WiLink6/WL127x, which is considered legacy product by TI and they no longer support it: http://processors.wiki.ti.com/index.php/WL127x WiLink6 is not even listed on TI's product page any more: http://www.ti.com/lsds/ti/wireless_connectivity/wilink/overview.page
On pandora, with wl1251, we basically have an unmaintained driver that has many compatibility issues with various router brands, ranging from bad speeds to not working connection at all. The driver is mainlined and even N900 uses it, still nobody ever fixed numerous driver+firmware issues this chip has.
I fear the same may happen with wl127x, although the driver seems to be much further developed, the number of mainline commits for it is sharply declining. It might make sense to consider some non-TI wifi module..
Hi,
Am 15.09.2014 um 22:31 schrieb Grazvydas Ignotas:
On Sun, Sep 14, 2014 at 11:56 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Am 12.09.2014 um 15:58 schrieb Grazvydas Ignotas notasas@gmail.com:
I guess audio is still to be selected, like BT/WLAN?
Plan for Audio: TWL6040 (placed on the CPU board!) since it has the best and easiest system integration with OMAP5 and has all required features (incl. built-in amplifiers). Can be replaced together with the CPU. And, it allows to have more digital signal processing (easier to shield analog signals from noise, especially GSM buzz). Potentiometer will get an ADC to digitally control attenuation. Can also be (mis)used as another game control :) And attenuation can alternatively/additionally controlled by on-screen sliders or +/- buttons giving maximum flexibility in user interface.
From my listening tests, TWL6040 sounds really bad on the EVM though,
there may be many reasons for that. Wrong firmware (where do I find the ABE_FW?) or non-optimal hardware on the EVM.
Theoretically (according to the data sheets of the Codecs) it should even be better and have lower noise than the Codec used in the OpenPandora.
but I don't have any alternatives to suggest.
Plan for BT/WLAN: WiLink6 WG7351 since the WiLink8 WG78xx modules by JorJin have less features and are bigger and unclear if they are really available.
WG7351 uses WiLink6/WL127x, which is considered legacy product by TI and they no longer support it: http://processors.wiki.ti.com/index.php/WL127x WiLink6 is not even listed on TI's product page any more: http://www.ti.com/lsds/ti/wireless_connectivity/wilink/overview.page
On pandora, with wl1251, we basically have an unmaintained driver that has many compatibility issues with various router brands, ranging from bad speeds to not working connection at all. The driver is mainlined and even N900 uses it, still nobody ever fixed numerous driver+firmware issues this chip has.
I fear the same may happen with wl127x, although the driver seems to be much further developed, the number of mainline commits for it is sharply declining.
Well, number of commits is not necessarily a good indicator. If a system is mature and most bugs have been fixed, the need for changes may decline simply because it works and no new features are demanded.
Unfortunately the modules with WiLink8 need more space.
What about the stability and maturity of the WiLink8 drivers? Sometimes I prefer well hung and mature components over the latest and greatest.
It might make sense to consider some non-TI wifi module..
If we find something compareable. We have looked at RedPine after embedded world:
http://www.redpinesignals.com/Modules/Internet_of_Things/nLink_Family/RS9113... http://www.mouser.de/Search/Refine.aspx?Keyword=redpine
and from promised feature set they are equally good.
But they are bigger, the price is twice as high, it is completely unclear which drivers exist and the modules can't be directly connected to the battery and 1.8V OMAP. So we need LDOs and glue logic around needing even more space and money.
So I fear the situation with alternative modules is even worse than with wl1251.
Something to consider instead of JorJin might be:
http://www.ti.com/lsds/ti/wireless_connectivity/wilink/products.page
BR, Nikolaus