Either power off the VIM with the remote control in Android (you then get a blue LED) or disconnect the power cord, but let the HDMI cable connected to the powered display.
After this sequence, there is 0.5 V on VCC3.3V because the HDMI_PW supply from the display flows through HDMI_SDA/SCL into the S905X, which is mostly off (except AO_5V on USBOTG_B_VBUS if the power cord is still there), so there are residual voltages flowing inside the S905X towards several pins, including VCC3.3V.
This residual voltage is an issue for extension boards connected on the J9 header if they use this VCC3.3V. We had an issue because of this using the PCA9555 and the TLV320AIC3104 because the power-on reset of the PCA requires VCC < 0.2 V, so a power cycle with the HDMI connected means a residual 0.5 V on VCC3.3V and no reset of the PCA, which then retains its previous on state, so the TLV is not properly initialized if its reset pin is controlled by the PCA, which may make the TLV break the I²C, so it’s not even possible to manually tell the PCA to reset the TLV by software.
This residual voltage may be an issue for other components as well, all the more it is also present on all the pins pulled up to VCC3.3V, and there are also lower residual voltages on other pins.
Using a local 3.3 V supply on the extension board is not always a possible solution either because of the residual voltages on the other pins, which might exceed the absolute maximum ratings of some components when off or during the power-on sequence.
Do you have any plan of completely isolating HDMI_PW from the rest of the VIM when AO_5V or PWR_EN is off?
Hi, Ben:
Yes, we also found this when we design VIM, and for the Residual voltage, different monitor with different voltage value. As we don’t except our end users will do more expandtion like what you did now then, so we thought it’s not a problem so we just leave it
Actually, we followed the Amlogic reference designing on this, and the HDMI_PW is make sure HDMI CEC features which let monitor/poweron wakeup VIM in sleep/poweroff state. And yes, we did have a plan to optmize the designing of VIM1, but still don’t have detailed plans and timeline on this yet.
May I know that your project requirement on VIM1? and is it possiable to chose another chip to achive your project?
I’ve tested the HDMI CEC wake up (i.e. waking up the VIM1 using the TV remote): it works in suspend (solid red LED) mode (but not always), but not in power-off (solid blue LED) mode. I don’t think it’s supposed to work in power-off mode as the only (if I didn’t miss anything on the schematic) power supply reaching the S905X in this case is AO_5V on USBOTG_B_VBUS, and this pin is probably only used for OTG detection and not to supply power to the SoC. Therefore, since the CEC signals only go to the SoC, they cannot wake up the SoC if it’s not at least partially powered. And if the CEC does not work in power-off mode, there is no point in not isolating HDMI_PW during power off to avoid the residual voltage.
We don’t want to switch to another board or chip. The VIM1 is just fine for our 4K HDR 60 fps decoding needs. What we would like for a VIM1 refresh would be:
To get rid of the residual voltages. For now, we have to add switches on our board controlled by PWR_EN on VCC3.3V and I2C_SCK/SDA_A/B.
To be able to choose the IR RC protocol and power key code to wake up the S905X from power off with U19 (currently, it’s hard-coded in this chip).
That the U20 RTC alarm can also wake up the S905X from suspend, and not only from power off with U19. Currently, we use the alarm of U20 to wake up the board from power off, and that of the S905X VRTC to wake up from suspend. We could live with that, though.
Yes, I was meant that Amlogic reference design with power off/on CEC feature, but it did not real hardware-level power off and on, it’s software-level which still need the built-in MCU of the SoC/S905X to powering on but CPU and other peripheral off.
As when both the built-in MCU share with the same power supply with CPU core, so to make the MCU on-state, the CPU will also occupy some current, we don’t think it’s idea, so we change the design and add an external MCU to manage the power. It means that if VIM1 want to support CEC power off/on feature in software-level, still have to keep external MCU powering on.
We will talked about this with our team if we resolve this in future batch VIM1, and thanks for the feedback!
