PinePhone v1.2 - Revision history

Kx: /* Changes from v1.1 */

2023-12-24T23:44:37Z

Changes from v1.1

← Older revision		Revision as of 23:44, 24 December 2023
Line 24:		Line 24:
	# The modem no longer has access to the I2C bus containing the sensors.		# The modem no longer has access to the I2C bus containing the sensors.
	# <tt>HBIAS</tt> is now connected to the headphone jack.		# <tt>HBIAS</tt> is now connected to the headphone jack.
			# Awinic AW3641EDNR replaces Sgmicro SGM3140 LED driver for camera flash and torch

	== Known issues ==		== Known issues ==

Fxc: /* Backlight */ added information

2023-02-20T19:22:54Z

Backlight: added information

← Older revision		Revision as of 19:22, 20 February 2023
Line 35:		Line 35:
	On PinePhone 1.0, this was not the case, PWM signal was directly fed to the CE pin of the regulator, and lowest brightness setting seems more stable. On the other hand, the lowest achievable brightness was brighter than on 1.1+.		On PinePhone 1.0, this was not the case, PWM signal was directly fed to the CE pin of the regulator, and lowest brightness setting seems more stable. On the other hand, the lowest achievable brightness was brighter than on 1.1+.

	Additionally there is also another backlight issue, where the brightness is lower when connecting a VBUS powered device, https://xnux.eu/log/#022.		Additionally there is also another backlight issue, where the brightness is lower when connecting a VBUS powered device, https://xnux.eu/log/#022. See [[PinePhone 1.2b R1318 backlight Hardware Fix]].

	=== USB ===		=== USB ===

Fxc: back link

2023-02-20T09:41:34Z

back link

← Older revision		Revision as of 09:41, 20 February 2023
Line 1:		Line 1:
	The PinePhone v1.2 is a hardware revision of the PinePhone that was shipped in 2020 as UBports Community Edition.		The PinePhone v1.2 is a hardware revision of the [[PinePhone]] that was shipped in 2020 as UBports Community Edition.

	This page contains information and resources which are specific to the UBports Community Edition (v1.2 PCB) revision of the PinePhone. For other revisions or for resources related to all PinePhone revisions, see [[PinePhone#Hardware revisions]].		This page contains information and resources which are specific to the UBports Community Edition (v1.2 PCB) revision of the PinePhone. For other revisions or for resources related to all PinePhone revisions, see [[PinePhone#Hardware revisions]].

Fxc: Dev page, please don't alter it. RGB labels already mentioned

2021-11-02T20:46:58Z

Dev page, please don't alter it. RGB labels already mentioned

← Older revision		Revision as of 20:46, 2 November 2021
Line 6:		Line 6:

	* [http://files.pine64.org/doc/PinePhone/PinePhone%20v1.2%20Released%20Schematic.pdf Hardware schematic v1.2] (2020-03-10, for the UBports Community Edition)		* [http://files.pine64.org/doc/PinePhone/PinePhone%20v1.2%20Released%20Schematic.pdf Hardware schematic v1.2] (2020-03-10, for the UBports Community Edition)
	~~- ERROR: Schematic labels 'PD18-LED-R' and 'PD19-LED-G' should properly be labelled 'PD18-LED-G' and 'PD19-LED-R'~~

	~~- ERROR: Page 11 LED2 pin labels 'B+','R+' and 'G+' do not correspond to the appropriate colours, they should be 'G+','R+' and 'B+' respectively~~

	== Changes from v1.1 ==		== Changes from v1.1 ==

Kourama: /* Schematics */

2021-11-02T19:24:59Z

Schematics

← Older revision		Revision as of 19:24, 2 November 2021
Line 6:		Line 6:

	* [http://files.pine64.org/doc/PinePhone/PinePhone%20v1.2%20Released%20Schematic.pdf Hardware schematic v1.2] (2020-03-10, for the UBports Community Edition)		* [http://files.pine64.org/doc/PinePhone/PinePhone%20v1.2%20Released%20Schematic.pdf Hardware schematic v1.2] (2020-03-10, for the UBports Community Edition)
			- ERROR: Schematic labels 'PD18-LED-R' and 'PD19-LED-G' should properly be labelled 'PD18-LED-G' and 'PD19-LED-R'

			- ERROR: Page 11 LED2 pin labels 'B+','R+' and 'G+' do not correspond to the appropriate colours, they should be 'G+','R+' and 'B+' respectively

	== Changes from v1.1 ==		== Changes from v1.1 ==

KJ7RRV at 03:35, 23 October 2021

2021-10-23T03:35:25Z

← Older revision		Revision as of 03:35, 23 October 2021
Line 49:		Line 49:


	[[Category:PinePhone]]		[[Category:PinePhone]]
			[[Category:PinePhone Revisions]]

Fxc: lang

2021-09-29T12:31:52Z

lang

← Older revision		Revision as of 12:31, 29 September 2021
Line 11:		Line 11:
	The v1.2 mainboard revision changes the routing of several GPIOs to fix bugs and to improve power management. Therefore, it needs an updated device tree. The state of PL6 at boot can be used to distinguish between v1.1 (it can be pulled high) and v1.2 (it will remain low).		The v1.2 mainboard revision changes the routing of several GPIOs to fix bugs and to improve power management. Therefore, it needs an updated device tree. The state of PL6 at boot can be used to distinguish between v1.1 (it can be pulled high) and v1.2 (it will remain low).

	# The WiFi module's <tt>CHIP_EN</tt> input (connected to the ~~kill~~ switch) is now pulled down, so the WiFi will turn off reliably when the switch is off.		# The WiFi module's <tt>CHIP_EN</tt> input (connected to the privacy switch) is now pulled down, so the WiFi will turn off reliably when the switch is off.
	# PL2 is now connected to the WiFi module's reset pin, allowing the WiFi to be turned off or reset in software.		# PL2 is now connected to the WiFi module's reset pin, allowing the WiFi to be turned off or reset in software.
	# The magnetometer's <tt>DRDY</tt> pin is now connected to PB1, allowing interrupt-driven periodic sensor readings.		# The magnetometer's <tt>DRDY</tt> pin is now connected to PB1, allowing interrupt-driven periodic sensor readings.

DrRac27: The other link was dead and I assume this is the same file.

2021-08-19T17:10:03Z

The other link was dead and I assume this is the same file.

← Older revision		Revision as of 17:10, 19 August 2021
Line 44:		Line 44:
	In SW this can only be worked around by manual selection of PinePhone's data and power role by the user.		In SW this can only be worked around by manual selection of PinePhone's data and power role by the user.

	Hardware workaround is to desolder U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles (see https://~~megous~~.~~com~~/~~dl/tmp~~/pp-usbc-fix.jpg).		Hardware workaround is to desolder U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles (see https://xnux.eu/devices/pp-usbc-fix.jpg).

	Hardware fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn't have the "quick discharge function" that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. User ''mozzwald'' used NCP334FCT2G as a replacement.		Hardware fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn't have the "quick discharge function" that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. User ''mozzwald'' used NCP334FCT2G as a replacement.

Fxc: Reverted edits by Dsimic (talk) to last revision by Olf

2021-04-26T20:24:29Z

Reverted edits by Dsimic (talk) to last revision by Olf

← Older revision		Revision as of 20:24, 26 April 2021
Line 28:		Line 28:

	=== Backlight ===		=== Backlight ===
	Backlight LED current regulation depends on gpio0-ldo voltage stability due to feedback voltage from the AP3127B's current sensing resistor being modified via SoC's PWM pin and pullup resistor to gpio0-ldo. gpio0-ldo also powers the CTP controller and light/proximity sensor, among other things. When backlight brightness is very low and the CTP controller actively communicates on the I2C bus the backlight blinks heavily. It's not a very good idea to tie boost converter's current regulating feedback circuit to the potential source of noise, especially since the noise will have much larger effect when the backlight LED current is low. It's possible this can be mitigated if C1110 can be raised to 22-47uF range, or by changing the resistor values in the feedback circuit.

	~~On PinePhone 1~~.0, ~~this was~~ not the ~~case~~, ~~PWM signal was directly fed to~~ the ~~CE (EN) pin of~~ the ~~AP3127B regulator, and lowest brightness setting seems more stable~~. ~~On the other hand~~, the ~~lowest achievable brightness was brighter than on~~ the ~~post-1.1 revisions~~.		Backlight LED current regulation depends on gpio0-ldo voltage stability due to feedback voltage from current sensing resistor being modified via SoC's PWM pin and pullup resistor to gpio0-ldo. gpio0-ldo also powers the CTP controller and light/proximity sensor, among other things. When backlight brightness is very low and the CTP controller actively communicates on the I2C bus the backlight blinks heavily. It's not a very good idea to tie boost converter's current regulating feedback circuit to the potential source of noise, especially since the noise will have much larger effect when the backlight LED current is low. It's possible this can be mitigated if C1110 can be raised to 22-47uF range, or by changing the resistor values in the feedback circuit.

	~~Another way~~ for ~~fixing this issue could be to revert~~ the backlight ~~circuit to its state in the revision 1.0~~ of ~~PinePhone; see [https://forum~~.~~pine64.org/showthread.php?tid=13353&pid=91458#pid91458 this forum thread]~~ for ~~further imformation~~.		PWM duty cycle for the lowest brightness of the backlight is also not very predictable, varying from 7-20% (tested with a small sample size of 2 devices). Therefore it's not possible to come up with a single device tree brightness settings that will work for everyone, requiring per-device calibration.

	PWM ~~duty cycle for~~ the lowest brightness of the ~~backlight is also not very predictable~~, ~~varying from 7-20% (tested with a small sample size of 2 devices)~~. ~~Therefore it's not possible to come up with a single device tree brightness settings that will work for everyone, requiring per-device calibration~~.		On PinePhone 1.0, this was not the case, PWM signal was directly fed to the CE pin of the regulator, and lowest brightness setting seems more stable. On the other hand, the lowest achievable brightness was brighter than on 1.1+.

	Additionally, there is another backlight issue, ~~manifested by~~ the ~~backlight becoming reduced~~ when a VBUS-powered device ~~is connected; see [~~https://xnux.eu/log/#022 ~~this link] for further information~~.		Additionally there is also another backlight issue, where the brightness is lower when connecting a VBUS powered device, https://xnux.eu/log/#022.

	=== USB ===		=== USB ===

Dsimic: /* Backlight */ Small clarity improvements

2021-03-14T17:21:09Z

Backlight: Small clarity improvements

← Older revision		Revision as of 17:21, 14 March 2021
Line 28:		Line 28:

	=== Backlight ===		=== Backlight ===
	Backlight LED current regulation depends on gpio0-ldo voltage stability due to feedback voltage from current sensing resistor being modified via SoC's PWM pin and pullup resistor to gpio0-ldo. gpio0-ldo also powers the CTP controller and light/proximity sensor, among other things. When backlight brightness is very low and the CTP controller actively communicates on the I2C bus the backlight blinks heavily. It's not a very good idea to tie boost converter's current regulating feedback circuit to the potential source of noise, especially since the noise will have much larger effect when the backlight LED current is low. It's possible this can be mitigated if C1110 can be raised to 22-47uF range, or by changing the resistor values in the feedback circuit.		Backlight LED current regulation depends on gpio0-ldo voltage stability due to feedback voltage from the AP3127B's current sensing resistor being modified via SoC's PWM pin and pullup resistor to gpio0-ldo. gpio0-ldo also powers the CTP controller and light/proximity sensor, among other things. When backlight brightness is very low and the CTP controller actively communicates on the I2C bus the backlight blinks heavily. It's not a very good idea to tie boost converter's current regulating feedback circuit to the potential source of noise, especially since the noise will have much larger effect when the backlight LED current is low. It's possible this can be mitigated if C1110 can be raised to 22-47uF range, or by changing the resistor values in the feedback circuit.

	On PinePhone 1.0, this was not the case, PWM signal was directly fed to the CE pin of the regulator, and lowest brightness setting seems more stable. On the other hand, the lowest achievable brightness was brighter than on 1.1+.		On PinePhone 1.0, this was not the case, PWM signal was directly fed to the CE (EN) pin of the AP3127B regulator, and lowest brightness setting seems more stable. On the other hand, the lowest achievable brightness was brighter than on the post-1.1 revisions.

	Another way for fixing this issue could be to revert the backlight circuit to its state in the revision 1.0 of PinePhone; see [https://forum.pine64.org/showthread.php?tid=13353&pid=91458#pid91458 this forum thread] for further imformation.		Another way for fixing this issue could be to revert the backlight circuit to its state in the revision 1.0 of PinePhone; see [https://forum.pine64.org/showthread.php?tid=13353&pid=91458#pid91458 this forum thread] for further imformation.