Running APIO4 as a 1.8V domain instead of 3.0V

Edge
1

Gouwa suggested I post this here as the answer might be useful to others too.

The RK3399 GPIO/I2C/SPI run in several power domains, some of which are configurable. Lines such as GPIO4_Cn and GPIO4_Dn run in the APIO4 domain which the RK3399 apparently supports as either 1.8V or 3.0V.

These are documented on the Edge v13 schematic as 3.0V, but can I configure the PMIC to run APIO4 in 1.8V mode instead without breaking anything on the Edge, i.e. set VLDO8 at 1.8V to run APIO4_VDD at 1.8V (instead of 3.0V), and VLDO6 at 1.8V to set the bias APIO4_VDDPST to 1.8V (instead of 1.5V) as in the datasheet, effectively making these 1.8V GPIOs?

I know some of these 3.0V lines are used for control purposes, e.g. HDMI_CEC, USB_PWR_EN, CHG1_CC_INT_L, etc., but as far as I can see, all of these places will work equally well with 1.8V vs 3.0V logic levels, e.g. the HDMI_CEC is level-shifted to 3.3V anyway, the SGM2551A EN-pin supports high levels as low as 1.4V. (I know this would also change the DBG_UART pin voltage from 3.0V to 1.8V, but that’s fine in my application.)

If it won’t cause problems, is it as simple as changing the relevant microvolt levels in the RK808-D setup in the device tree? I’d test this myself but can’t do so until the boards ship, so thought I’d ask the question instead!

1 Like
2

Hi Chris:
My I know that why you need change VLDO8 to 1.8V? as there are a lot IO with 1.8V level.

Yep, should be no problem, but we also haven’t tested with 1.8V yet :smile: if needed @goenjoy will take a try an update here.

We already finished the 100PCS trial production of the Edge-V at V12 revision, but we finally release version is V13, if for ODM project, the V12 should works for you.

Good day!

2 Likes
3

Hi Gouwa. In a finished product which docks the module via an MXM3 connector to our board, I agree there’s loads of 1.8V IO already, and I could probably just ignore the 3.0V ones. (Is there 1.8V hardware PWM?)

However, while doing early prototyping, it’d be really handy to bodge tests together via the Edge IO, and two out of four GPIO lines there are 3.0V, including the PWM line, which is quite an unusual logic level. (I don’t think 3.0V inputs are officially 3.3V tolerant either, looking at the RK3399 datasheet, although clearly fine use them as 3.3V outputs given standard logic input thresholds.)

Four GPIO lines and an SPI bus that are all at the same logic level (whether 1.8V or 3.3V) is just a bit handier if configuring that way doesn’t upset the board.

I’d be interested to hear what happens if you do, but don’t worry if you don’t get time: I can test it when the production Edge board ships over and report back here for anyone else who’s curious.

Brilliant, thanks. I guess the final release version of the non-V Edge is v14? I have one on order to play with, looking forward to seeing it in action when manufacturing is completed.

As I said in email, the Edge is a really nice design and positioned in a great niche between SBC and SoM levels of integration. Very appealing for product designers to integrate. I wish you every success with it. :+1:

2 Likes
4

Yep, will complete the mass production early next month.

Sadly nope :smile:

Actually, when we define the PIN OUT of the golden fingers, we also found this problem. You might need a 3.3V to 1.8V logic for that.

1 Like
5

…or just cheat and run APIO4 at 1.8V if that works! :wink:

1 Like
6

@goenjoy please do a test and and update here when you available.

Good day!

1 Like
7 
--- a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
@@ -581,12 +581,12 @@
                        vcc_3v0: LDO_REG8 {
                                regulator-always-on;
                                regulator-boot-on;
-                               regulator-min-microvolt = <3000000>;
-                               regulator-max-microvolt = <3000000>;
+                               regulator-min-microvolt = <1800000>;
+                               regulator-max-microvolt = <1800000>;
                                regulator-name = "vcc_3v0";
                                regulator-state-mem {
                                        regulator-on-in-suspend;
-                                       regulator-suspend-microvolt = <3000000>;
+                                       regulator-suspend-microvolt = <1800000>;
                                };

Above is apio4 modified to 1.8V power domain.

After apio4 was modified to 1.8V, there were two problems as follows:

  • MIPI LCD does not light up. Because the LCD IO power domain is 3.3V

  • CHG1_CC_INT_L acts as the interrupt pin, while the output level ranges from 3.0 to 5.5, while the IO power domain as the input pin is 1.8V. This will cause the IO port level mismatch

1 Like
8

Many thanks for testing this, really useful and helpful. I’d expect #1 when connecting a 3.3V device to an interface that has been reconfigured as 1.8V, but #2 is puzzling me.

U22 and U39 are identically configured FUSB302BMPX for each of the two type C ports. Pin 5 INT# on U22 is connected to CHG_CC_INT_L = GPIO1_A2 in the 1.8V GPIO1 domain. Pin 5 INT# on U39 is connected to CHG1_CC_INT_L = GPIO4_D6 in the APIO4 domain.

Presumably if it’s okay to connect U22 to a 1.8V input, it’s similarly fine to connect identical U39 to an input configured as 1.8V, so this shouldn’t cause any breakage? (Is there something different about U39 which I’ve missed?)

Finally, I note that the rk3399 data sheet suggests changing the bias voltage vcc_1v5 = VLDO6 to 1.8V as well as vcc_3v0 = VLDO8. Does this matter? (Might even be a printing mistake on the data sheet?)

Best wishes,
Chris.

9

Ah, FUSB302BMPX Int# is active-low open-drain (see page 5 of the datasheet https://www.onsemi.com/pub/Collateral/FUSB302B-D.PDF ) which explains why U22 can connect to 1.8V and U39 to 3.0V input in the standard configuration… but this should also mean it doesn’t cause a problem to hook it to 1.8V APIO4? Did you see a problem when you tested this - if so, it may have a different cause?

10

Sorry. I misread it. The second problem does not exist.

1 Like